System and method of providing a leader-follower multi-asset portfolio

ABSTRACT

Disclosed is a system and method of implementing a leader-follower set of smart contracts on a blockchain. The method includes establishing a follower multi-asset blockchain based trustless smart contract for managing a multi-asset portfolio, inserting into the multi-asset blockchain based trustless smart contract an authorization for a leader multi-asset blockchain based trustless smart contract to send messages from the leader multi-asset blockchain based trustless smart contract to the multi-asset blockchain based trustless smart contract regarding a leader rebalancing of the follower multi-asset blockchain based trustless smart contract to yield a follower multi-asset blockchain based trustless smart contract, and modifying the follower multi-asset blockchain based trustless smart contract based at least in part on the leader rebalancing of the leader multi-asset blockchain based trustless smart contract.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of, and priority to, U.S.Provisional Patent Application No. 62/399,763, filed on Sep. 26, 2016,U.S. Provisional Patent Application No. 62/453,416, filed on Feb. 1,2017, U.S. Provisional Patent Application No. 62/453,350, filed on Feb.1, 2017, U.S. Provisional Patent Application No. 62/453,379, filed onFeb. 1, 2017, U.S. Provisional Patent Application No. 62/453,384, filedon Feb. 1, 2017, the entire contents of each of which are hereinincorporated by reference in their entireties.

TECHNICAL FIELD

The present disclosure relates to implementing a leader-followerapproach to blockchain-based multi-asset portfolios.

BACKGROUND

In traditional approaches to asset management, assets are typically heldby entities in a custodial manner. This creates a risk to the buyer, asthe buyer's assets are subject to any errors or improprieties by theentities in custody of the assets, such as fraud, forged data, deleteddata, and so forth. An enormous legal and regulatory structure exists toprevent, detect, and dissuade such errors by setting forth processes andrules for record keeping of company data, such as documents, emails,transactions, contracts, etc., and setting forth specific disclosure andfiduciary requirements.

Financial institutions are also subject to frequent audits designed toensure those records and processes accurately represent the firm'sassets, liabilities, and operations. Despite the frequent audits and thelegal and regulatory structure that exists, fraud and insolvency casesoccur across the entire landscape of asset management with surprisingregularity. The continual failure to prevent these issues highlights therisks inherent in using third parties to manage assets. Currenttechnologies similarly fail to prevent these issues.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure will be readily understood by the following detaileddescription in conjunction with the accompanying drawings in which:

FIG. 1 illustrates example computing components of a computing deviceaccording to one or more aspects of this disclosure;

FIG. 2 illustrates an example process for portfolio swaps based on smartcontracts and blockchain technologies;

FIG. 3 illustrates an example graphical interface for building aportfolio of assets;

FIG. 4 illustrates an example graphical interface for buying a portfolioof assets;

FIG. 5 illustrates an example graphical interface for completing paymentfor a portfolio of assets;

FIG. 6 illustrates an example graphical interface for viewing thecurrent composition, status, and value of a portfolio of assetsselecting portfolio actions;

FIG. 7 illustrates a method aspect for a smart contract creator;

FIG. 8 illustrates a method aspect for a multi-validator oracle;

FIG. 9 illustrates an example graphical interface for rebalancing aportfolio of assets;

FIG. 10 illustrates an example method aspect for a rebalancing approach;

FIG. 11 illustrates an example graphical interface for sharing aportfolio of assets with users on a network;

FIG. 12 illustrates an example graphical interface for following aportfolio of assets;

FIG. 13 illustrates an example graphical interface for providing leaderboards based on various portfolios of assets;

FIG. 14 illustrates a method for enabling a leader/follower assetmanagement approach;

FIG. 15 illustrates an example graphical interface for liquidating aportfolio of assets; and

FIGS. 16A and 16B illustrate example methods of managing a multi-assetportfolio.

DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

Blockchain technology can reduce or eliminate the risks in assetmanagement. Blockchain technologies depend on the existence of variousnetworks such as the Internet, and allow users to exchange assets suchas digital currency using a decentralized verification systemimplemented and deployed over multiple servers. The process for buying,securing/storing and vetting blockchain assets has many technical stepsand challenges. For example, any investor who wants to build a portfolioof blockchain assets should (1) conduct in-depth research and analysisinto which blockchain assets to buy, (2) research and register atmultiple asset exchanges to purchase blockchain assets, (3) securelygenerate and store the private keys for each blockchain asset theinvestor wants to purchase, and (4) manually buy or sell assets whenthey want to change the composition of the portfolio.

Previous solutions for trading assets allow users to gain exposure tothousands of available tickers (like stocks, bonds, currencies, etc.).Such applications are designed for tickers to be traded on a “singleasset basis”. That is, each and every swap is for a single asset (i.e.Apple for IBM, or USD for euros, etc.). The bitcoin blockchain systemcan be used for blockchain assets and cryptocurrencies. However, thebitcoin blockchain system requires a wallet for every asset. The walletstores the user's private key and address for that asset. For everydifferent type of cryptocurrency, a user must download the respectivewallet that stores a private key and an address for that user. Thisrequirement for a separate wallet, private key, etc. for each type ofblockchain asset is cumbersome, and creates significant technicallimitations and burdens pertaining to data storage, bandwidth, digitalsecurity, computing efficiency, software and data compatibility, etc.

The disclosed technologies provide a technical solution to address thelimitations and burdens pertaining to data storage, bandwidth, digitalsecurity, computing efficiency, software and data compatibility, andprovides various technical advantages which eliminate or reduce assetmanagement risks and other limitations. For example, the conceptsdisclosed herein can reduce or eliminate such risks, as well as otherrisks such as the risk of custodianship in the blockchain asset tradingworld and beyond, including the broader financial services andinvestment management industries.

Disclosed herein are technologies and applications for blockchain-basedsmart contract driven asset management. The approaches disclosed hereinallow users to: (1) Build a portfolio of blockchain assets from auser-friendly interface, (2) Purchase an entire portfolio in a singletransaction (i.e., rather than a single asset basis transaction,transactions can involve a plurality of assets being acquired in asingle step), (3) Secure the entire portfolio under a single privatekey, which only the investor controls, from beginning to end (i.e. nocustodial or counterparty risk), (4) Manage and maintain multipleblockchain assets and asset types without storing and managing adifferent wallet for each type of the blockchain assets, (5) Rebalancethe portfolio as desired through a single signed transaction, (6)Leverage the collective knowledge of the crowd to “socially” design acrypto portfolio, (7) Manage a portfolio of assets and “follow” topblockchain asset portfolio managers and traders without giving upcustody of their assets—a new type of asset management process), and (8)Store, trade, and manage an entire group of assets using a singleprivate key.

Blockchain technologies provide significant improvements overtraditional asset management and data recording procedures. Blockchainrepresent an evolution in web and database technology. Leveragingblockchain technology enables new services and service improvements notpreviously feasible or even possible. For example, the approaches hereincan implement blockchain technologies to provide a new service andtechnical environment for portfolio management with reduced/eliminatedcustodial risk, such as the leader/follower concepts further describedherein, which allows a leader to direct the follower's investmentswithout taking custody of the assets.

The approaches set forth herein can provide secure and efficienttechnologies and procedures for managing a portfolio of blockchainassets and implementing various asset management functionalities such asportfolio rebalancing. The approaches herein can implement a distributedarchitecture for hosting a blockchain and distributed information whichtogether can enhance asset and portfolio information, asset andinformation security, and user control and flexibility. The processoutlined herein can also reduce costs.

With this technology, users can own and manage portfolios of blockchain(or any digital) assets using the blockchain, smart contracts, andrelated infrastructure disclosed herein. Users do not need to keep coinson an exchange or even interface with an exchange. Users do not need todownload the wallets/clients of any specific blockchain asset which theywant to purchase and store. Instead, users can own and manage portfoliosof blockchain assets using the blockchain, smart contracts, and relatedinfrastructure disclosed herein.

While the description herein focuses on blockchain assets, it should benoted that the technologies herein can also be used to managenon-blockchain assets and build portfolios with non-blockchain assets,such as stocks, bonds, real estate, contracts, leases, and other typesof assets. The technologies herein can be used to build portfolios ofany assets having pricing data-feeds. The benefits and use cases forbuilding non-blockchain asset portfolios can vary from those associatedwith building blockchain asset portfolios. This is due at least in partto the differences in the infrastructure and industry associated withthese types of assets.

The approaches disclosed herein provide significant advantages oftransparency and auditability. In the present disclosure, “the contractis the code,” which means that using blockchain technology and smartcontracts, everything is transparent and secured by cryptography.Individuals cannot forge, erase, or add data inappropriately. The systemprovides complete transparency in view of who owns the assets and theirprovidence over time. This new system provides a new infrastructure withgreater cyber security and overall security, and eliminates the need totrust others and rely on third parties to be honest. One non-limitingexample of a platform for developing and deploying smart contracts onthe blockchain is the Ethereum Virtual Machine.

The computer code or code referenced herein represents the intent ofparties to the smart contract. The smart contract as implemented hereinreduces the amount of interpretation with respect to the contract byestablishing that the code is a literal manifestation of the intent ofthe parties, thus avoiding ambiguity.

A multi-asset swap option disclosed herein limits or eliminates the riskinherent in the use of financial swap arrangements which requiretrusting one or more parties to deliver or otherwise satisfy obligationsupon settlement, known as performance. Every swap has counterparty risk,and this risk will be priced and paid ultimately by one or more partiesin the arrangement. Not having mathematical certainty of performance inthe swap contract is an unnecessary loss to all involved in thecontract.

The problems outlined above, among others, are addressed by the conceptsdisclosed herein. For example, the approaches disclosed herein canimplement a blockchain-based smart contract paired with an oracle datafeed in which the performance and settlement of the swap arrangementoccurs autonomously and without risk to either party. Both parties, whenthey enter in the contract, know with mathematical certainty that theother side does not need to perform anything. With the approachesherein, there is no counterparty risk and no need for a clearing house.The blockchain-based smart contract creates an auditable, transparenttrail and the code executes the intent of the parties. The use of thesmart contract herein reduces the likelihood of failure to perform,eliminates non-performance risks, and reduces the cost of entering,managing, and executing a swap agreement.

The use of the smart contract herein can also reduce the cost of dealingwith such failures to perform and eliminates the need for a centralclearing house. In the derivatives world, there are over-the-counter(OTC) derivatives which can be an agreement directly between the twoparties. In that case, the parties have counterparty risk should one orthe other party not fulfill their obligations. In the case where bothparties employ the services of a clearing house as a trusted thirdparty, there is always a risk that the trusted third party may notmanage and enforce the swap. The approaches herein eliminate the risksin both scenarios above, as well as their associated costs. Again, inthe disclosed solution, there is no need for a clearing house, and inthe OTC scenario, both parties do not have trust each other thuseliminating counterparty risk.

Non-limiting examples and aspects of the technologies disclosed hereininclude, without limitation, a trustless blockchain multi-asset‘swaption” mechanism, a multi-asset trustless swap rebalance mechanism,a trustless multi-asset leader-follower mechanism, a contract creatormechanism and a multi-validator oracle. One or more of these individualexamples or features can be combined and/or otherwise function togetherwith other examples or features disclosed herein, to form a specificapplication or configuration. For example, one or more of the componentsdisclosed herein can be combined together to create a portfolio indexswap marketplace (herein called a “PRISM”). “PRISM” is a working productname and refers to an application and service that enables buying andselling of multi-asset portfolios based on blockchain technology andsmart contracts.

A number of examples will be provided related to blockchain assets orcryptocurrencies, such as Bitcoins, Ethereum, and other digitalcurrencies and assets. However, it is noted that the concepts hereinapply to portfolios of any type of blockchain asset, digital currency orasset, and/or non-blockchain assets such as stock equities, bonds,commodities, real estate, contracts, currencies (e.g., dollars), etc.

As previously noted, users do not have to keep assets on an exchange, orinterface with an exchange, third party or counterparty. This eliminatessignificant risks such as fraud, non-performance, breach of duty, theft,etc. Moreover, users do not have to download the specific wallets orclients for respective blockchain assets that users want to purchase andstore securely. Instead, users can own and manage one or more portfoliosof assets, each of which can include a variety of assets such asblockchain assets and/or “traditional assets” (e.g., equities, bonds,etc.) using a blockchain and associated security features likepublic/private key infrastructure. Each individual portfolio is securedusing the public/private key infrastructure and transactions areverified using the blockchain.

In this respect, the present technologies provide a new computinginfrastructure, environment, and procedure for managing digital assetsand multi-asset portfolios, with significant improvements over existingtechnologies and procedures, including technologies and procedures fordata storage, security, management, communication, efficiency, etc. Thenew computing infrastructure, environment, and procedure providedistributed data storage, enhancement, security, control, processing,verification, etc., and enhance the information and functionality ofdata and systems across the distributed environment. The new processdisclosed herein allows value creators (the portfolio managers ortraders) to connect directly with consumers (those users who need theirassets managed professionally) without numerous intermediaries likeclearing houses, custodians, banks, etc. This is accomplished at leastpartly by collapsing the infrastructure costs of such intermediariesonto the blockchain and associated technologies (smart contracts, PKIinfrastructure, modern cryptography, etc.).

Blockchain technologies are designed for trading single assets and areincapable of performing multi-asset transactions or managing portfoliosof different types of assets, such as blockchain assets andnon-blockchain assets (e.g., real-world assets). However, thetechnologies disclosed herein address these limitations and providevarious other improvements to blockchain and non-blockchaintechnologies, including flexibility, security, and performanceimprovements. For example, the technologies provide a multi-assetsolution which allows portfolios to be built with different types ofassets and enables swaps of entire portfolios as opposed to merelysingle asset transactions.

The disclosed technologies also implement a smart contract based oraclethrough which the smart contract can receive and validate pricing data,including multi-sig, multi-validation, or fully decentralized.

In a multi-signature context, rather than using a single private key toauthorize the transaction, the system uses multiple private keys to signthe transaction together before the transaction happens. The system canrequire a number of keys which can vary in different configurations,such as 2 out of 3 possible private keys to verify the transaction or 99out of 100, or 3 out of 8, and so forth. The multi-signature arrangementremoves a point of failure from the process and provides a safertransaction. This can apply to the oracle disclosed herein and/or toother components.

The present technologies also provide a unique leader-followerfunctionality along with various benefits including mitigation ofcustodial risk. Unlike current solutions, the present technologies alsoprovide the architecture and functionality for enabling in-contractrebalancing of a portfolio of assets, which can be performed for theentire portfolio without opening and closing every single asset swapevery time the user wants to rebalance the portfolio. The technologiesalso provide an architecture and environment that integrates a socialnetworking component. For example, with the disclosed technologies,users can share their portfolio with other users on one or morenetworks, such as a social network. Users can also view and selectportfolios of other users to follow selected portfolio(s) from the otherusers.

The disclosed technologies can be deployed using different platforms andenvironments, including desktop applications, browser applications,etc., and are not limited to a specific platform. The presenttechnologies also provide an array of smart contract security features,such as the ability to “pause contracts”, “manually override contracts”,etc., as well as a “training wheels” method as further described herein.In some aspects of the present disclosure, only the buyer can initiatesettlement, which can prevent settlements being triggered without thebuyer's consent, such as based on margin calls, the expiration of time,or by the seller. The buyer has the option to settle a swap at any timeand the seller can be prevented from triggering a settlement. This canprovide significant security and usability implications.

The technologies disclosed herein also provide a new architecture andcode-base which allows for a unique “leader and follower utility.” Thisfunctionality allows a “leader” to invest/allocate digital assetscorresponding to “followers”, without taking custody of those assets.This feature and functionality eliminates typical custodial arrangementsand their associated risks. With the disclosed technologies, a thirdparty does not have to take custody of client assets. Instead, usersretain possession of their assets, which can be aggregated into“portfolios” stored and/or verified using a blockchain network.Portfolios can include various types of blockchain assets (e.g.,cryptocurrencies, etc.), as well as other non-blockchain assets.

A uniquely implemented blockchain-based oracle, which can providecurrent pricing information and can be used as a data feed in thepresent application. This oracle and its configuration in the presentapplication can include a number of security features, such as a “manualoverride”, “contract-pause”, “training wheels” processes, and others.

The present disclosure includes systems, methods, and computer-readablestorage devices for implementing blockchain-based smart contracts forasset management, including trustless blockchain swaption contracts ofmulti-asset portfolios for example. In some examples, a system or methodcan include receiving, from a buyer and at a smart contract, anidentification of a portfolio of blockchain assets (e.g., digitalcurrencies such as Bitcoin or Ethereum), receiving, from the buyer, anamount that the buyer will invest in the portfolio of blockchain assetsand receiving, based on prevailing exchange rates, a number ofblockchain assets in the portfolio.

The system or method further includes receiving a confirmation from thebuyer of the portfolio having the number of blockchain assets,calculating, by an entity, a cost of the portfolio of blockchain assetsto yield a contract, receiving the amount and excess collateral from thebuyer as a buyer acceptance of the contract, and receiving an entityacceptance of the contract by receiving an amount from the seller orother entity (i.e., an asset value amount such as a value in dollars orvalue of cryptocurrency) at the smart contract. Private keys of asending address associated with the entity can be used as an entitysignature key for the contract.

The system or method further includes receiving, at the smart contract,an indication that the buyer wants to close the contract. Thisindication can be associated with a signed message from a buyer privatekey. The system or method can also include settling the arrangement viathe smart contract based on a current value of the portfolio, which canbe calculated based on pricing data received from a trusted valuationentity, such as the oracle or another source.

Also disclosed is an approach for rebalancing multi-asset smartcontracts. In some examples, a system or method includes establishing amulti-asset blockchain-based trustless smart contract for managing amulti-asset portfolio, receiving an indication, from an individualassociated with the multi-asset portfolio, of a desire to rebalance themulti-asset portfolio, presenting the individual with an interface torebalance the multi-asset portfolio, receiving, through the interface,input from the individual including a rebalancing of the multi-assetportfolio and updating the multi-asset blockchain-based trustless smartcontract to yield a modified multi-asset blockchain-based trustlesssmart contract which incorporates the rebalancing.

The smart contract can be the same contract, existing in the same placeon the blockchain but with a new “state”. The new state reflects the newcomposition of the portfolio which is recorded in the blockchain. Theblockchain is the transparent and relatively immutable record of statechanges which the contract undergoes. The system writes a new entry inthe blockchain that reflects the new portfolio composition. In anotheraspect, the system can create a new contract but with differentparameters (asset allocations). The old contract can be discarded,deleted or made inactive.

The indication of the desire to rebalance the multi-asset portfolio caninclude a request to rebalance one or more assets in the multi-assetportfolio or add/delete one or more assets in the multi-asset portfolio.

DESCRIPTION

The present disclosure addresses the various issues and limitations inthe art outlined above, such as security limitations, performancelimitations, inefficiencies, control limitations, flexibilitylimitations, lack of transparency, infrastructure limitations, etc.Example features and functionalities of the present disclosure includetrustless blockchain multi-asset swaption mechanisms, trustlessmulti-asset rebalance mechanisms, trustless multi-asset leader-followermechanisms, smart-contract creator mechanisms, multi-validator oraclesystems, etc. These example features and functionalities can beimplemented in a distributed network and computing environment which canprovide various advantages in security, storage, efficiency, bandwidth,computation, control, flexibility, performance, etc., and can support avariety of software application and computing platforms. One or more ofthese individual components can be combined and work together with anyother one or more of the components in various configurations.

The disclosure first turns to FIG. 1 which illustrates example hardwarecomponents for a computing system that can be implemented for variousaspects of the present disclosure. The disclosure will then turn to adescription of example multi-asset management mechanisms, architectures,and concepts.

With reference to FIG. 1, an exemplary system and/or computing device100 includes a processing unit (CPU or processor) 110 and a system bus105 that couples various system components including the system memory115 such as read only memory (ROM) 120 and random access memory (RAM)125 to the processor 110. The system 100 can include a cache 112 ofhigh-speed memory connected directly with, in close proximity to, orintegrated as part of the processor 110. The system 100 copies data fromthe memory 115, 120, and/or 125 and/or the storage device 130 to thecache 112 for quick access by the processor 110. In this way, the cacheprovides a performance boost that avoids processor 110 delays whilewaiting for data. These and other modules can control or be configuredto control the processor 110 to perform various operations or actions.Other system memory 115 may be available for use as well. The memory 115can include multiple different types of memory with differentperformance characteristics. It can be appreciated that the disclosuremay operate on a computing device 100 with more than one processor 110or on a group or cluster of computing devices networked together toprovide greater processing capability. The processor 110 can include anygeneral purpose processor and a hardware module or software module, suchas module 1 132, module 2 134, and module 3 136 stored in storage device130, configured to control the processor 110 as well as aspecial-purpose processor where software instructions are incorporatedinto the processor. The processor 110 may be a self-contained computingsystem, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric. The processor 110 can include multiple processors, such as asystem having multiple, physically separate processors in differentsockets, or a system having multiple processor cores on a singlephysical chip. Similarly, the processor 110 can include multipledistributed processors located in multiple separate computing devices,but working together such as via a communications network. Multipleprocessors or processor cores can share resources such as memory 115 orthe cache 112, or can operate using independent resources. The processor110 can include one or more of a state machine, an application specificintegrated circuit (ASIC), or a programmable gate array (PGA) includinga field PGA.

The system bus 105 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output system (BIOS) stored in ROM 120 or the like, may providethe basic routine that helps to transfer information between elementswithin the computing device 100, such as during start-up. The computingdevice 100 further includes storage devices 130 or computer-readablestorage media such as a hard disk drive, a magnetic disk drive, anoptical disk drive, tape drive, solid-state drive, RAM drive, removablestorage devices, a redundant array of inexpensive disks (RAID), hybridstorage device, or the like. The storage device 130 is connected to thesystem bus 105 by a drive interface. The drives and the associatedcomputer-readable storage devices provide nonvolatile storage ofcomputer-readable instructions, data structures, program modules andother data for the computing device 100. In one aspect, a hardwaremodule that performs a particular function includes the softwarecomponent stored in a tangible computer-readable storage device inconnection with the necessary hardware components, such as the processor110, bus 105, an output device such as a display 135, and so forth, tocarry out a particular function. In another aspect, the system can use aprocessor and computer-readable storage device to store instructionswhich, when executed by the processor, cause the processor to performoperations, a method or other specific actions. The basic components andappropriate variations can be modified depending on the type of device,such as whether the computing device 100 is a small, handheld computingdevice, a desktop computer, or a computer server. When the processor 110executes instructions to perform “operations”, the processor 110 canperform the operations directly and/or facilitate, direct, or cooperatewith another device or component to perform the operations.

Although the exemplary embodiment(s) described herein employs a storagedevice such as a hard disk 130, other types of computer-readable storagedevices which can store data that are accessible by a computer, such asmagnetic cassettes, flash memory cards, digital versatile disks (DVDs),cartridges, random access memories (RAMs) 125, read only memory (ROM)120, a cable containing a bit stream and the like, may also be used inthe exemplary operating environment. According to this disclosure,tangible computer-readable storage media, computer-readable storagedevices, computer-readable storage media, and computer-readable memorydevices, expressly exclude media such as transitory waves, energy,carrier signals, electromagnetic waves, and signals per se.

To enable user interaction with the computing device 100, an inputdevice 145 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 135 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 100. The communications interface 140generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic hardware depicted may easily be substituted forimproved hardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system embodiment ispresented as including individual functional blocks including functionalblocks labeled as a “processor” or processor 110. The functions theseblocks represent may be provided through the use of either shared ordedicated hardware, including, but not limited to, hardware capable ofexecuting software and hardware, such as a processor 110, that ispurpose-built to operate as an equivalent to software executing on ageneral purpose processor. For example the functions of one or moreprocessors presented in FIG. 1 can be provided by a single sharedprocessor or multiple processors. (Use of the term “processor” shouldnot be construed to refer exclusively to hardware capable of executingsoftware.) Illustrative embodiments may include microprocessor and/ordigital signal processor (DSP) hardware, read-only memory (ROM) 120 forstoring software performing the operations described below, and randomaccess memory (RAM) 125 for storing results. Very large scaleintegration (VLSI) hardware embodiments, as well as custom VLSIcircuitry in combination with a general purpose DSP circuit, may also beprovided.

The logical operations of the various embodiments are implemented as:(1) a sequence of computer implemented steps, operations, or proceduresrunning on a programmable circuit within a general use computer; (2) asequence of computer implemented steps, operations, or proceduresrunning on a specific-use programmable circuit; and/or (3)interconnected machine modules or program engines within theprogrammable circuits. The system 100 shown in FIG. 1 can practice allor part of the recited methods, can be a part of the recited systems,and/or can operate according to instructions in the recited tangiblecomputer-readable storage devices. Such logical operations can beimplemented as modules configured to control the processor 110 toperform particular functions according to the programming of the module.For example, FIG. 1 illustrates three modules Mod1 132, Mod2 134 andMod3 136 which are modules configured to control the processor 110.These modules may be stored on the storage device 130 and loaded intoRAM 125 or memory 115 at runtime or may be stored in othercomputer-readable memory locations.

One or more parts of the example computing device 100, up to andincluding the entire computing device 100, can be virtualized. Forexample, a virtual processor can be a software object that executesaccording to a particular instruction set, even when a physicalprocessor of the same type as the virtual processor is unavailable. Avirtualization layer or a virtual “host” can enable virtualizedcomponents of one or more different computing devices or device types bytranslating virtualized operations to actual operations. Ultimatelyhowever, virtualized hardware of every type is implemented or executedby some underlying physical hardware. Thus, a virtualization computelayer can operate on top of a physical compute layer. The virtualizationcompute layer can include one or more of a virtual machine, an overlaynetwork, a hypervisor, virtual switching, and any other virtualizationapplication.

The processor 110 can include all types of processors disclosed herein,including a virtual processor. However, when referring to a virtualprocessor, the processor 110 includes the software components associatedwith executing the virtual processor in a virtualization layer andunderlying hardware necessary to execute the virtualization layer. Thesystem 100 can include a physical or virtual processor 110 that receiveinstructions stored in a computer-readable storage device, which causethe processor 110 to perform certain operations. When referring to avirtual processor 110, the system also includes the underlying physicalhardware executing the virtual processor 110.

The disclosure now turns to a description of example multi-assetmanagement mechanisms, architectures, and related concepts in accordancewith various aspects of the disclosed technologies.

FIG. 2 illustrates an example application and service 200 for managingthe buying and selling of asset groups. In this example, the applicationuses financial swaps, implemented via a smart contract. The swap can be“secured” and “enforced” through smart contracts. In some examples, thesmart contract can be written in one or more computing languages, suchas Solidity, the Turing Complete language of Ethereum (or any otherblockchain-operable language that would result in the same or similarfunctionality as disclosed herein). Swaps can be a promise or agreementfor each party (the Buyer and the Seller) to swap asset exposures forsome amount of time. With swaps, the underlying assets are neverexchanged—all that is exchanged is a contract that binds each party topay one another based on the change in value of the underlying assets asrecorded by an agreed upon external data, such as the oracle 210.

The application can run smart contracts, which can include autonomousapplications or code that run as programmed without downtime,censorship, fraud or third party interference. The application can runon a custom built blockchain architecture, which provides a powerfulshared global infrastructure that can move values around and representownership of property. This infrastructure enables developers managerecords, transactions, and values in a distributed fashion according toinstructions, all without a middle man or counterparty and custodialrisk. For clarity and explanation purposes, the example application willbe described herein with reference to a smart contract on a platformlike Ethereum.

Financial swaps like index swaps and swaptions are financial engineeringtools for both trading and risk management. Billions of dollars of thesetypes of swaps are traded daily through the traditional banking system.However, the present disclosure creates an entirely new process forcreating, securing, and delivering these swaps to both consumers andinstitutional users (buyers or sellers). The following discussionoutlines various aspects of the disclosed solution.

The disclosed approaches provide novel technologies for multi-assetportfolio management. In some aspects, the disclosed approaches can useblockchain technology to create, enforce, and secure swaps withoutcounterparty, custodial, and other risks, and cryptocurrency orblockchain assets to collateralize swaps. The disclosed technologies canalso provide a new type of swap, which can be referred to as “a customportfolio swap”, and differs significantly from an index swap in variousways.

For example, an index swap has fixed components which are usually basedon a large public index calculated and created by a third party, e.g.the Dow Jones Industrial Index or the S&P 500 index. The buyer of anindex swap receives that index and cannot customize it. These indexesrepresent an “investment strategy”. By contrast, the “custom portfolioswap” disclosed herein, which a user can create using the disclosedapplication, is not limited to an index with fixed components, and canbe customized by the user. Thus, the “custom portfolio swap” canrepresent the user's own investment strategies, unique from any singleindex swap on the market today.

Index swaps are further limited to certain assets based on the indexesavailable. However, many assets do not have an index. For example,crypto-currencies and real world assets do not have an index or exchangetraded funds (ETF) available. Moreover, index swaps (as well as allswaps) rely on data from trusted third-parties. On the other hand, thedata used in a “custom portfolio swap” comes from trustless oracles,which differ from trusted third-parties.

Other differences between the disclosed swaps and other swaps includethat the disclosed swaps will always be “over-collateralized”, asopposed to other swaps which typically require fractional margin toenter a swap (vastly under-collateralized). As a result, the disclosedswaps have no counterparty risk and swaps are immune to insolvency foreither party. Further, almost all swaps in their current form aredesigned to be traded on an institutional level, as opposed to adirect-to-consumer product. By contrast, the disclosed technologyprovides swaps designed as a consumer product, and include significantdifferences in architecture in order to support this consumer leveldesign.

Swaps are a form of financial derivative. The interest rate swapbusiness has 300+ trillion dollars in outstanding notional value. In thecurrent financial system, swaps provide limited security through: (1) alegally binding contract between the parties to the swap; (2)collateral, margin, and other requirements imposed by clearing housesand brokers around the globe; and (3) the perceived creditworthiness ofthe two parties to the swap (this is the source of counterparty risk).The new swap disclosed herein can be “secured” and “enforced” throughsmart contracts written in a blockchain-operable language.

In the context of blockchains and cryptocurrencies, smart contracts are:(1) pre-written logic (computer code); (2) stored and replicated on adistributed storage platform (e.g. a blockchain); (3) executed/run by anetwork of computers (usually the same ones running the blockchain); and(4) can result in ledger updates (cryptocurrency payments, etc.).

In other words, smart contracts are programs that execute “if thishappens then do that” that are run on, and are verified by, manycomputers to ensure trustworthiness. If blockchains provide distributedtrustworthy storage, then smart contracts provide distributedtrustworthy calculations. Below are three examples illustrating use ofsmart contracts in the disclosed technologies. The first exampleillustrates use or replacement of bank accounts with embeddedinstructions, the second example illustrates replacement of legalesewith computer code and the third example provides an actual smartcontract example.

Replacement of Bank Accounts with Embedded Instructions

Bank accounts typically have specific instructions and parameters thatdefine the account's behavior and preferences. For example, bankaccounts maintain a balance which indicates the funds available for thatbank account. The bank accounts can have instructions defining basicpayment and balance management operations for the account. Suppose auser configures the user's bank account to deduct automatic payments toa particular entity (e.g., landlady, utility companies, etc.) for afixed amount every month, and send the deducted payments to theparticular entity. If the balance of the account falls below the amountof an automatic payment configured, the account would not havesufficient funds to cover the amount for the automatic payment. In thisscenario, the automatic payment will typically fail, causing the user topossibly receive a fine for insufficient funds and another workflow tobe triggered. There are instructions that the user can have set up forthe user's bank account, which can define basic conditions or operationsfor the bank account.

However, in the context of bank accounts, this process is managed by thebank or institution associated with the bank account. By contrast, asmart contract runs on a blockchain and is therefore managed by manyparties rather than a single entity. The distributed control andmanagement of smart contracts provides many advantages as previouslyexplained, such as, without limitation security, reliability, andtransparency. Moreover, as further explained herein, smart contractsprovide more granular control and a significantly greater degree offlexibility and functionality.

Replacing Legalese with Computer Code

A smart contract provides code which automates the “if this happens,then do that” part of contracts. Computer code behaves in expected waysand does not have the linguistic nuances of human languages. Code hasless potential points of contention or ambiguity. In the case of smartcontracts, the computer code is replicated on many computers anddistributed or decentralized on a blockchain. The computer code isexecuted by the various computers, which together agree on the resultsof the code execution. In some cases, a user can have a paper contractwith all the “whereas” clauses that lawyers employ, and a clause thatpoints to a smart contract on a blockchain. The smart contract canprovide, for example, “both parties to the smart contract agree to runcode x and we will abide by the results of the code.”

Example Smart Contract

Below is an example smart contract illustrating example computer codewritten for use on the Ethereum blockchain:

contract tokenRecipient { function receiveApproval(address _from,uint256 _value, address _token, bytes _extraData); } contract MyToken { /* Public variables of the token */  string public standard = “Token0.1”;  string public name;  string public symbol;  uint8 publicdecimals;  uint256 public totalSupply;  /* This creates an array withall balances */  mapping (address => uint256) public balanceOf;  mapping(address => mapping (address => uint256)) public allowance;  /* Thisgenerates a public event on the blockchain that will notify clients */ event Transfer(address indexed from, address indexed to, uint256value);  /* Initializes contract with initial supply tokens to thecreator of the contract */  function MyToken(   uint256 initialSupply,  string tokenName,   uint8 decimalUnits,   string tokenSymbol   ) {  balanceOf[msg.sender] = initialSupply;   // Give the creator allinitial tokens   totalSupply = initialSupply; // Update total supply  name = tokenName; // Set the name for display purposes   symbol =tokenSymbol;  // Set the symbol for display purposes   decimals =decimalUnits;  // Amount of decimals for display purposes  msg.sender.send(msg.value);  // Send back any ether sent accidentally }  /* Send coins */  function transfer(address _to, uint256 _value) {  if (balanceOf[msg.sender] < _value) throw; // Check if the sender hasenough   if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Checkfor overflows   balanceOf[msg.sender] −= _value;  // Subtract from thesender   balanceOf[_to] += _value; // Add the same to the recipient  Transfer(msg.sender, _to, _value);  // Notify anyone listening thatthis transfer took place  }  /* Allow another contract to spend sometokens in your behalf */  function approve(address _spender, uint256_value)   returns (bool success) {   allowance[msg.sender][_spender] =_value;   return true;  }  /* Approve and then comunicate the approvedcontract in a single tx */  function approveAndCall(address _spender,uint256 _value, bytes _extraData)   returns (bool success) {  tokenRecipient spender = tokenRecipient(_spender);   if(approve(_spender, _value)) {    spender.receiveApproval(msg.sender,_value, this, _extraData);    return true;   }  }  /* A contractattempts to get the coins */  function transferFrom(address _from,address _to, uint256 _value) returns (bool success) {   if(balanceOf[_from] < _value) throw;   // Check if the sender has enough  if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Check foroverflows   if (_value > allowance[_from][msg.sender]) throw; // Checkallowance   balanceOf[_from] −= _value;  // Subtract from the sender  balanceOf[_to] += _value; // Add the same to the recipient  allowance[_from][msg.sender] −= _value;   Transfer(_from, _to,_value);   return true;  }  /* This unnamed function is called wheneversomeone tries to send ether to it */  function ( ) {   throw; //Prevents accidental sending of ether  } }

The example contract generates 10 thousand tokens to the creator of thecontract, and then allows anyone with enough balance to send it toothers. These tokens are the minimum tradeable unit and cannot besubdivided, but for the final users could be presented as a 100 unitssubdividable by 100 subunits, so owning a single token would representhaving 0.01% of the total.

The above example contract provides unique control and flexibilitiesthat automated banking payments lack. For example, a user's bank is theultimate guardian of the user's bank account. The bank has completecontrol, and can arbitrarily add money to the account or subtract it. Ina blockchain ecosystem, there should be no single source of control. Thedistributed layout with consensus mechanisms in blockchain allowsmultiple parties to check and re-check and update the ledgers. Anythingin the blockchain that does not conform to pre-agreed rules, can berejected by any of the participants.

The above example contract also provides code control and validation asopposed to automated banking accounts. With a bank account, there issome logic creating transactions on a monthly basis. That code resideson a computer and is executed by a party (the bank). The bank has fullpossession and control. In the banking context, there are no externalvalidations. With smart contracts running on a blockchain, the logicruns in parallel on all participating computers, and the results arecompared by all participants. Participants only change their own versionof the ledger if they agree with the results. Thus, each participant hascode control and validation capabilities.

In addition, the above example contract provides a level of transparencythat is not available in the banking context. For example, for allparticipants in a blockchain ecosystem to run the same code, eachverifying the others, the logic of the smart contract is available andvisible to all. This allows any participant to review a smart contract,and decide whether to use the logic after first reviewing the logic. Ifthe participant does not like or approve of the logic, that participanthas the option to reject the logic (i.e., not to use it). There can besmart contracts for general usage, as well as specific smart contracts.The transparency is useful to stakeholders of the contract to agree onwhat happens.

The above example contract provides significant flexibility to makeadjustments and customizations that are not otherwise available inbanking systems. For example, the logic that a user can run within theirbank account is limited to recurring payments, and possibly a few otherbasic options. A user cannot, for example, automate a payment from theirsalary account to their savings account every day it is sunny, then haveit all sent back when there is a storm (the ‘saving up for a rainy day”smart contract). By contrast, a “Turing complete” smart contract can doanything that a normal computer can do, including numerous operationsand customizations.

Smart contracts are useful when there are multiple parties who may nottrust each other fully, as each party can compare their version ofevents with each other. For example, when two banks do a complexderivative trade with each other that does not go through a clearinghouse, it is called an “Over The Counter” or OTC trade. These areagreements between the two banks, without third party validation. Thesetrades are usually bets—i.e. variations of “if this happens before theend of the year then you pay me, else I pay you”. Both parties have acopy of the original trade documents (the terms and conditions of thetrade), and they both have a view on the external dependencies of thetrade. The parties should both therefore agree on the outcome of thetrade i.e. who wins the bet. However, parties may not always agree onthe outcome of the trade.

A mismatch or “break” can occur in the dependencies, where parties donot agree on the outcome of the trade, due to a number of things. Forexample, problems can include: (1) A mutual misunderstanding of theinitial trade terms; (2) Confusion due to multiple copies of theoriginal trade terms (usually there is back-and-forth on the wording ofthe documents, with in-house lawyers on both sides trying to protecttheir interests); or (3) A disagreement with what actually happened inthe external dependencies.

With a smart contract, there is only one set of trade terms, written incomputer code, which is more precise than a contract written in legalterms, and agreed upon up-front. The external dependencies (price ofoil, share price of a stock, etc.) can be fed in via a mutually agreedfeed. The contract will live on a blockchain, and run when a conditionoccurs (e.g., when an event happens or the bet expires). The bet payoutcan be stored in the smart contract itself. The contract can be “primed”by both parties funding the account with their maximum loss, and thepayout is made when the condition occurs (e.g., the event). Also, a lotof trades in financial services are currently done on credit andmargined or collateralized; the necessity to pre-fund the total payoutwith the full value of the potential payout, in the currency/asset ofthe payout may not be attractive for some use cases. In another aspectof the application, concepts such as margin considerations can beimplemented as well in institutional cases where collateralization maybe too costly.

A further description of smart contract offerings in accordance withvarious aspects of the disclosed technologies is provided in thefollowing discussion.

Blockchains (e.g., Bitcoin, Ethereum, etc.) have varying degrees ofeffectiveness in running smart contracts. Bitcoin's platform is greatfor processing bitcoin transactions, but otherwise limited in computeability. Within the scripts of bitcoin transactions, there is a verylimited ability to implement rich logic. An example of what is possiblein bitcoin is logic requiring multiple signatories to sign a transactionbefore a payment is made, like needing two signatories in a check.However, major changes would need to be made to both the miningfunctions and the mining incentive schemes to enable smart contractsproperly on Bitcoin's blockchain.

Sidechains (i.e. blockchains connected to Bitcoin's main blockchain) canenable smart contract functionality by having different blockchainsrunning in parallel to Bitcoin. These sidechains can be programmed withan ability to jump value between Bitcoin's main chain and the sidechains, such that side chains could be used to execute logic.

NXT is a public blockchain platform which includes a selection of smartcontracts that are currently live. However it is not Turing Complete,meaning that a person cannot customize it as desired. Instead, the usermust use the existing templates. Ethereum, introduced above, is a publicblockchain platform which is currently the most advanced smart contractenabled blockchain. With a “Turing Complete” coding system,theoretically a user can put any logic into an Ethereum smart contract,and it will be run by the whole network. There are mechanisms in placeto prevent abuse, and users need to pay for compute power by passing in“ETH” tokens, which act as payment for the miners who run the code.

There are some questions and challenges with respect to the structuredescribed above. For example, decentralization is expensive. The morecomputers that run code, the more expensive things get for the endusers. A system that has 10,000 computers running the user's code canincur significant costs: the computer operators are likely not going toprovide their computer infrastructure and run the code on their computerinfrastructure free of charge. In a public network, the users pay to runall the machines on the network. Having every computer (“node”) in asystem stores data (e.g. a copy of the blockchain, or a portion of theblockchain corresponding to specific assets/portfolios) and run thesmart contract code embedded within the blockchain is more expensivethan having one or two participants run the code on individualcomputers.

It is typically sufficient to have the code written on a blockchain sothe parties can see the smart contract they are committing to. In thiscase, the code can be run privately, perhaps by the very parties to thetransaction. This would save on compute costs, but increase risk becauseonly the transaction parties would be verifying the transaction/contractaction (whereas normal blockchain interactions are verified by anonymousservers).

Another factor in contracts is optionality. In many contracts, clausesare written into things to create a channel for arbitration. For examplein a flat rental agreement, wear-and-tear from tenants is acceptable,but major damage needs to be repaired. How does code define thesethings? Force majeure is present in many contracts to allow forwiggle-room for the parties involved. In a smart contract environment,how does one party call that without abusing it or referring to a humanarbitrator? These issues can be addressed through smart contracts.Ultimately, shared ledgers will have a role to play in removing the needfor trust among multi-party agreements. Smart contracts make sense forall parties by reducing operational risk, and can provide automatedtrustworthy workflow between parties without a central specificcoordinator. However, in the disclosed application, there is no need forany type of subjective arbitration since crypto-currencies pricing andtrading data is highly public, replicated, and simple to understand. Anytwo observers can easily agree on the pricing data coming from the APIof a public crypto-asset exchange.

The following description provides details of an application from auser's perspective. FIG. 2 illustrates the overall process 200 for anexample application in accordance with various aspects of thedisclosure. By way of example, FIG. 2 shows a series of stepsimplemented by a portfolio index swap marketplace (PRISM) to create aportfolio of assets. Every portfolio index swap marketplace created canbe a swap of one or more assets. In the marketplace, there are at leasttwo parties to the trade and a smart contract 206. The parties are theportfolio buyer 202 and the portfolio seller 204. For clarity,throughout the rest of this document, the portfolio buyer may bereferred to as the portfolio buyer, the buyer, the PB, or the usercollectively; and the portfolio seller may be referred to as theportfolio seller, the seller, the PS, or a business entity.

Solidity, the Ethereum Virtual Machine and the Ethereum blockchaincollectively work to enforce the smart contract that allows a singletrustless portfolio to exist and execute. Swaps represent a type ofpromise, or agreement, for each party (the buyer and the seller) to swapasset exposures for some amount of time. With swaps, the underlyingassets are not exchanged. All that is exchanged is a contract that bindseach party to pay one another based on the change in value of theunderlying assets as recorded by some agreed upon external data, like abenchmark, price feed, or in this case, the multi-validator oracle 210.

The multi-validator oracle 210 is an ensemble of blockchain-basedsmart-contracts and a set of applications (e.g., JavaScript basedapplications) that enable the validation and authentication of datasourced from the public APIs of any website in the world. This data ispushed to a blockchain-based smart-contract called the oracle (or anyother name with similar functionality) 210. The oracle 210 is used toprovide information to decentralized applications. More specifically,the oracle 210 can provide a data feed to the smart contract 206.

The trade can be explained in the context of a contract for difference(or CFD) example. Assume Alice wants to bet on the change in nextquarter's US GDP. She creates the buyer portfolio 202 and the terms ofthe smart contract 206. For example, she creates a smart contract thatincludes a formula likePAYOUT=((ALICE_PREDICTION−GDP1Q2014/GDP4Q2013−1)*GEARING) and funds itwith 10,000 ETH. The script in the contract specifies that anyone whosends 10,000 ETH to this contract 206 will take the other side of thistrade. Say Bob creates a seller portfolio 204 and accepts the offer. Thescript also contains the public key of an “oracle” 210, e.g. a trustedwebsite that publishes economic statistics for the purpose ofauthoritatively fixing the settlement value of CFD's. After X days, thescript in the contract 206 consults the oracle 210, pays a small fee tothe oracle 210, and gets signed value for GDP1Q2014, which the scriptchecks against the oracle's public key. Script then computes the formulaand sends Alice max(10000+PAYOUT,0) ETH and Bob max(10000−PAYOUT,0) ETH.

The smart contract 206 swap mechanism enables two parties, a “buyer” anda ‘seller,” to establish opposite positions in a trustless swaparrangement for exposure to a set of arbitrary assets. One of theproblems addressed by the smart contract structure is that financialswap arrangements require trusting one or more parties to deliver orsatisfy obligations upon settlement (performance). Every swap thus hascounter-party risk, and this risk must be priced and paid ultimately byone or more parties in the arrangement.

The smart contract herein provides a technical solution to this issue.The following is a brief summary of the process with reference to FIG.2. The blockchain-based smart contract 206 is a trustless multi-assetswap mechanism (TMASM) paired with a data-feed oracle 210, in whichperformance and settlement of a swap arrangement occurs automaticallyand without risk to either party. The swap is established by the buyer202, who selects one or several assets to which the buyer seeksexposure. The swap is accepted by the seller 204, who agrees to hold theother side of the same position. Stated in another way, the buyer 202offers a contract to the seller 204, in which buyer 202 promises to paythe seller 204 the “fixed leg” of the swap, in return for the seller 204paying the value of the portfolio (the “floating leg”) when, and onlywhen, the contract is closed by the buyer 202. The buyer is making apromise to the seller to pay them a certain amount which is theportfolio's value at the time of the purchase. The time of the paymentwill be in the future. Assume, at the time of the purchase, theportfolio value is 100 ETH. The fixed amount is therefore 100 ETH thatthe buyer promises to pay the seller upon closing out the contract inthe future. In swaps language, the buyer 202 has offered a contract tothe seller 204 wherein the buyer 202 promises to pay the seller 204 100ETH (aka, the “Fixed Leg”), in return for the seller 204 paying thebuyer 202 the value of the portfolio (aka, the “Floating Leg”), when—andonly when—the contract is closed by the buyer 202. The buyer 202 canchoose to close the contract at any time, but the seller 204 cannot.Terms such as “close”, “settle”, or “liquidate” can mean that the buyer202 has elected to close the contract and retrieve their portion of thesettlement funds from the contract.

The seller 204 receives the buyer's 202 request/offer and calculates theprice of the contract and sends that information back to the buyer 202.The calculation can be considered a service fee or commission charged bythe seller 204 for entering the contract with the buyer 202. The servicefee (say 1 ETH) will need to be calculated for each portfolio which anyuser wants to purchase, since portfolios can be different in terms oftheir respective coins, the total investment amount, and othervariables.

The buyer 202 accepts the terms of the swap contract by sending 125 ETHto the smart contract. 100 ETH pays for the investment in the portfolio,while the other 25 ETH can be the excess collateral required for thetrade. In one aspect, if there is a service fee of 1 ETH, 24 ETH can bethe collateral and 1 ETH can represent the service fee, for a total of125 ETH. The buyer 202 effectively signs the contract using the privatekeys of the Ethereum address from which the 125 ETH were sent. Theseller 204 is notified that the contract has been ‘accepted’ by thebuyer 202. The seller 204 also accepts the contract by sending 125 ETHto the smart contract. The smart contract is now holding 250 ETH, andwill continue to hold the 250 ETH until the buyer 202 chooses to closethe contract, at which time the contract will be settled.

Upon acceptance by both parties, both the buyer 202 and seller 204submit a blockchain transaction into the smart contract 206, whichincludes the sum of a principal amount (derived from a value of theselected assets) and a collateral amount (derived from the preferencesof the buyer and/or seller). In one aspect, the transaction is theacceptance.

Upon receipt of both transactions, the swap contract 206 is activated,existing solely on the blockchain (for example, Ethereum's blockchain).The smart contract 206 utilizes a data feed (oracle 210) to periodicallycalculate the value of each party's position. The buyer 202 may closethe swap contract at any time, at which point the smart-contract willtransact proportionate assets to the buyer 202 and the seller 204(divided from among the principle and collateral deposited by bothparties), based on the rise or fall of the underlying portfolio.

The portfolio buyer 202 has been able to enter that entire portfolio ofassets without actually having to go out and purchase them and takephysical custody of the assets. The process reduces the exposure of riskto the buyer 202, and increases the convenience and speed of obtainingexposure to those assets. On the back end, the portfolio seller 204,which can be an individual or a business entity, will act like aclearinghouse, but without taking custodial ownership of the assets. Theportfolio seller can design and implement the smart contracts whichanybody can see. The seller can take a fee for creating and managing thesmart contract and participating in the selling process.

As noted in the example above, the portfolio buyer 202 contributed 100ETH into the smart contract 206 as principal, plus 25 ETH as excesscollateral. The seller 204 contributes 125 ETH at the same time. This isthe seller's acceptance of 100 ETH plus 25 ETH collateral. The contract206 then holds 250 ETH 208.

The seller 204 can hedge its position in the contract by purchasing theunderlying coins that make up buyer 202's portfolio from an array ofcrypto-asset exchanges and then holds them in their own wallets. In thiscase, the seller 204 would go and purchase X litecoins, Y ripples, and Zdash, and hold them until the contract is closed by the buyer 202, atwhich time the seller 204 can sell them on the open market. As a result,the seller 204's exposure to this contract is perfectly hedged at alltimes in the future.

Now, fast forward to the time when the buyer 202 decides to close thecontract or ‘rebalance’ the portfolio. Assume that the time (T) is 7days. For simplicity, the disclosure will assume that the buyer 202wants to close the contract and not rebalance. When the buyer 202chooses to close the contract, the closure is initiated via a signedmessage from the buyer 202's private key, which the smart contract 206recognizes as the only signal that can initiate settlement of the trade.The smart contract 206 then settles the contract as follows. The smartcontract 206 calculates the current value of the portfolio based oncrypto-asset pricing data from the Oracle 210. In this example, at T=7,let's assume the value of the buyer's portfolio is 150 ETH. That meansthe value of the portfolio went up 50% from its initial value of 100ETH. The smart contract 206 calculates the amount of collateral andresulting proceeds to be sent to the buyer 202, while subtracting theseller's 204 commission for the trade (which, in this example, will be 1ETH). The settlement calculation can be: at T=7 the buyer 202 willreceive 174 ETH, while the seller 204 will receive 76 ETH. The buyergets 174 ETH=100 ETH (original investment amount)+50 ETH (profit fromportfolio appreciation)+25 ETH (original excess collateral amount)−1 ETH(the seller's commission). The seller gets 76 ETH=50 ETH (differencefrom original investment and loss on the trade)+25 ETH (original excesscollateral amount)+1 ETH (the seller's commission) Once this calculationis finished, the smart contract 206 allows the buyer 202 and the seller204 to withdraw their settlement amounts from the contract. Thiscontract has now been settled.

Next, the seller 204 lifts the contract hedge by selling underlyingcoins or assets. Based on this example, the seller 204 lost 50 ETH asthe result of its bet on the price movement of the buyer's 202 portfolioof assets. However, since the seller 204 purchased an exact mirror imageof that portfolio of assets when the trade was initiated, when the tradeis closed and settled, the seller 204 will sell that exact portfolio ofassets for which it has earned a profit of 50 ETH. Therefore, the seller204 has not lost any value on the trade, but has gained 1 ETH (thecommission). This is why the seller 204 was perfectly hedged 212 at thestart of the trade.

The process is “trustless” because it is executed automatically bysmart-contract code on a blockchain. There is no entity or group ofindividuals that can alter the terms of the contract or manipulate itssettlement. The smart contract always meets its obligations. Thedisclosed concepts herein bring the marketplace directly to the consumerin an entirely unique and novel way.

Normally, with a mortgage or a credit card, there are a number ofdifferent entities involved, including a bank. There are differentprocessors, counterparties, etc. that can be holding the money at somepoint. By contrast, the approaches disclosed herein transform thefinancial system into a blockchain smart contract that is packaged in aconsumer product that delivers to the consumer what the consumerwants—which is the ability to own a portfolio of assets and then alsohave the assets managed. In one aspect, a user can develop such aportfolio (for example, a portfolio of several blockchain assets orcryptocurrencies) without having to download an individual wallet foreach blockchain asset currency to buy that currency or leave the asseton deposit with a counterparty. Consequently, the user can develop aportfolio of assets without requiring multiple private keys, multipleapplications, and multiple counterparties. The user does not have tosend money to each exchange to buy blockchain assets in that type ofcurrency.

Thus, the concepts disclosed herein allow a user to create a multi-assetportfolio (e.g., a portfolio of multiple blockchain assets and/or anyother type of asset). For example, the concepts disclosed herein canaggregate the process so the user can, in simple, fast, and efficientway obtain a portfolio of blockchain assets without downloading anindividual wallet for each type of asset or leaving assets on depositwith a counterparty. In some examples, the management component can beaccomplished through a leader-follower functionality, as furtherdescribed herein. The end users can access such a service through a userinterface, an application, a website, an API, or any other means.

FIG. 2 in connection with other figures, referenced throughout thedisclosure, further demonstrates an example process. In the figure,reference to ETH is representative of any value/type of currency(including Bitcoin) depending on the platform desired. As noted above,in the first step, the user (buyer) creates their portfolio 202 ofblockchain assets. The user can create the buyer portfolio 202 via aninterface, such as web interface 300 shown in FIG. 3.

The web interface 300 can include a portfolio settings area 310 thatallows a user to enter various parameters for building the buyerportfolio 202. The user can enter various parameters in the portfoliosettings area 310 of the web interface 300 to create a portfolio. Forexample, the user can select blockchain asset components and respectiveasset percentages, such as A % Litecoin, B % Ripple, and C % DASH, froman assets area 304 and a percentages area 308. The user can provide aninvestment amount 302, such as 1 ETH, for the portfolio. The system canthen calculate respective assets amounts based on the prevailing ratesfrom the exchanges 214 coming from the blockchain asset data feed (theOracle) 210 at that point in time, such as X number of litecoins, Ynumber of ripples, and Z number of dash, and provide the respectiveasset amounts in an asset amounts area 306. The user can then select acontrol element 312 to create or purchase the portfolio. For example,the user can click on the control element 312 to build the portfolio. Insome cases, the control element 312 can include one or more labels, suchas “create portfolio” or “purchase portfolio”.

The system can summarize the portfolio with an asset value, a collateralvalue, a creation fee and a monthly fee as well. Any combination of thisdata can be presented. The user can then enter their ETH address tocontinue, which should be the same address used to send funds to themulti-asset portfolio. If the currency used for payment is ETH, the usercould send the number of ETH to the ETH address. A QR code could also beused to summarize the transaction. A bar can be included in thegraphical interface to instruct the user of their progress in how manyETH have been sent and how many are owed to complete the payment. Oncepayment is complete, a summary page can show the amount paid, an emailaddress for a receipt, and a link to enable the user to view theportfolio they just created and purchased. In some example interfaces,the system can present a listing of portfolios created by a particularowner (ETH address). Data can include a starting value in ETH (or othercurrency) and dollars, a current value, a listing of the portfolios byname, date created, rank, a graphic like a pie chart for example, aPrism ID, a starting value, a current value, a rate of return, and/or atotal value.

A further graphic can be presented which includes a left-to-rightgraphic of value in dollars or ETH that shows an initial value in onecolor and another increase in value in another color. In some examples,the interface can enable the owner of the portfolio to rebalance, sellor make the asset group public.

FIG. 4 illustrates an example interface 400 providing a purchase summaryfor the user and information for finalizing the purchase. The interface400 includes a purchase summary 402 indicating various details of thepurchase, such as a respective portfolio value, a respective asset, arespective asset percentage, and a respective asset amount. Theinterface 400 can also include a timer 404, which can indicate an amountof time left to pay. The interface 400 can also include a payment amountand location 406 identifying a payment amount and location (e.g., howmuch to send for payment and where to send the payment), in order tocomplete the purchase. Based on the interface 400, the user candetermine the amount of payment necessary and address for sending thepayment, which can be provided via the payment amount and location 406,as well as the amount of time left for transmitting the payment, asindicated in the timer 404

The interface 400 can also provide additional information for the user.For example, the interface 400 can include a notes and/or warnings area408, which can present any notes, details, or warnings for the userwhich pertain to the purchase. In some cases, the interface 400 can alsoinclude a reference to other payments to complete the contract, such as1 ETH for collateral or other fees or charges.

Once the portfolio is paid for and in an “active/open” state, the buyercan choose to close the contract at any time, but the seller cannot. Theterms “close”, ‘settle”, “liquidate”, or “exit” each generally mean thatthe buyer has elected to close the contract and retrieve their fundsfrom the contract. In one example, the buyer may commit to close withina specific period of time such that the seller is not held to thecontract indefinitely. Notices can be provided to the buyer if they donot act within a predetermined period of time such as 6 months. In caseswhere a buyer passes away, procedures would be put in place to handle anestate or other entity closing the contract. In another aspect, theseller can have the right to initiate the close of the contract,purchase an option to close the contract or to suggest closing thecontract which can be accepted by the buyer.

Referring back to FIG. 2, in step 2, the seller calculates and quotes aportfolio price to buyer. The seller calculates the cost of the assetgroup based on the buyer's offer and sends that information back to thebuyer. Additional details of this calculation will be discussed below.This calculation can be considered a ‘service fee” charged by the sellerand can be calculated for each portfolio which any user wants topurchase.

In step 3, the buyer accepts seller's quote and enters the contract. Inthis example, the buyer accepts the terms of the swap contract bysending 125 ETH (or other value or currency) to the smart contract 206.In once example, 1 ETH pays for the investment in the portfolio, whilethe other 24 ETH is the excess collateral required for the trade. Thesenumbers are purely exemplary—however, most transactions can require oneor more of the following portions: (1) the trade itself, (2) the cost ofperforming the trade, and/or (3) the excess collateral required for thetrade. The buyer 202 ‘signs” the contract using the private keys of theaddress from which the 125 ETH were sent.

Referring to FIG. 5, an interface 500 can be presented to providepayment details and receipt information. The interface 500 can provide aportfolio number label 502 with the number 506 for the portfolio, aswell as an email receipt input field 504 to allow the user to enter anemail address for receiving a receipt of the purchase.

Turning back to FIG. 2, the seller is notified that the contract hasbeen “accepted” by buyer 202. The seller 204 also “accepts” the contractby sending the seller's corresponding amount to the smart contract 206.In this example, the seller 204 accepts the contract by sending 125 ETHto the smart contract 206. Again, the private keys of the sendingaddress are seller's signature keys for the contract. The address for anEthereum contract can be deterministically computed from the address ofits creator (sender) and how many transactions the creator has sent(nonce). The nonce can be an arbitrary number that is used once for acryptographic communication. The sender and nonce are RLP (recursivelength prefix) encoded and then hashed with Keccak-256. Below is anexample pyethereum code:

-   -   def mk_contract_address(sender, nonce):    -   return sha3(rlp.encode([normalize_address(sender),        nonce]))[12:].

Below is a specific example with some discussion:

For sender 0x6ac7ea33f8831ea9dcc53393aaa88b25a785dbf0, the contractaddresses that it will create are the following:

-   -   nonce0=“0xcd234a471b72ba2f1ccf0a70fcaba648a5eecd8d”    -   nonce1=“0x343c43a37d37dff08ae8c4a11544c718abb4fcf8”    -   nonce2=“0xf778b86fa74e846c4f0a1fbd1335fe81c00a0c91”    -   nonce3=“0xfffd933a0bc612844eaf0c6fe3e5b8e9b6c1d19c”

The smart contract 206 is at this stage holding 4 ETH, indicated by theamount 208 in FIG. 2. The smart contract 206 will continue to hold theamount 208 until the buyer chooses to close the contract, at which timethe contract will be settled.

In optional step 4, the seller 204 can hedge the contract 212. This isan optional choice as part of the process and is not required to managethe portfolio. The seller can “hedge” its position in the contract bypurchasing the underlying assets or currency that make up the seller'sportfolio from an array of blockchain asset exchanges 214, and thenholding the purchased assets or currency in the seller's own wallet(s).In this case, the seller 204 would purchase X litecoins, Y ripples, andZ dash, and hold them until the contract is closed by buyer 202, atwhich time they will sell them on the market. As a result, seller'sexposure to this contract is perfectly hedged (or nearly perfectlyhedged) at all times in the future.

FIG. 6 illustrates a summary of the portfolio with an interface 600providing a summary of the portfolio. The interface 600 includes acurrent value 602 and data such as the percentage of gain or loss.Feature 604 provides options for the buyer to sell, rebalance, share, oradd to leaderboards. At some point, the buyer will decide to close thetrade or rebalance the portfolio using the interface 600. Assume this istime (T)=7 days.

FIG. 7 illustrates an example method for creating a customized smartcontract. In this example, the method includes receiving one or moreparameters input by a user via a user interface for a customized smartcontract (702). For example, the one or more parameters can include afirst parameter and a second parameter associated with a creation of acustomized smart contract. The method can include authenticating the oneor more parameters via a public/private key associated with the user(704) and deploying the customized smart contract onto a blockchain(706).

The method can include generating the customized smart contract toimplement the one or more parameters. Using an intermediary smartcontract (which can be a contract creator), the process can betransparent and trustless, as the final smart contract (which varies peruser) holding the funds or assets is, itself, created by a precedingcontract that is the same for all users.

The customized smart contract can be deployed on a blockchain. The smartcontract can run without a custodial risk, such as a risk of loss ofsecurities held in custody occasioned by the insolvency, negligence orfraudulent action of the custodian or a sub-custodian. Thereduction/elimination of custodial risk can apply to other aspects ofthis application and not just the contract creator.

The smart contract is between a first party and a second party. In thisexample, no third party holds custody of the assets associated with thesmart contract or the smart contract itself. Non-limiting examples ofthe one or more parameters include parameters associated with one ormore auctions, wallets, real estate transactions, stock trades, altcointrades, crowdfunding, contracts, legal services, currencies, and soforth. The customized smart contract can be coded, stored and replicatedand a distributed platform.

FIG. 8 illustrates an example method for providing a multi-validatororacle similar to oracle 210 shown in FIG. 2. The example method caninclude receiving a notification, at a multi-validator oracle, from anexternal smart contract, requesting data from the multi-validator oracleto be provided to the external smart contract according to a set ofparameters to yield requested data (802). The notification or call fromthe external smart contract can be based on a trigger, such as arebalancing notice, a message, market data, a user request, a marketcondition or threshold, an event, and so forth.

Based on the notification, the method includes providing the requesteddata to the external smart contract (804). Here, the multi-validatororacle can gather the requested data from at least one publicapplication programming interface for a website that providesinformation associated with the requested data. In some examples, themulti-validator oracle can also gather at least a portion of therequested data from one or more other sources, such as databases, viarespective calls for example.

In one implementation, two validators are used. However, in ageneralized version of the multi-validator oracle, the system can add orsubtract validators. An example of M of N validators can produce thesame result for the oracle data to be considered “truth”. The method canalso include multi-validating the requested data based on a firstverification from a first private key and a second verification from asecond private key (806).

The multi-validation can include requiring at least two validations fromthree or more possible validations. The multi-validation can includerequiring a subset of validations from a superset of validations, wherethe superset of validations is larger than the subset of validations. Inone example, each validator can pull the raw source data from the publicAPIs of each exchange, perform one or more calculations on it, andreturn the result(s). The data, and calculation result, is validated(which means it can be used for settlement) when both validators producethe same result and agree that the result is the “truth”. The reason whythe system uses this process is that smart contracts themselves can'tmake calls to public APIs and so they operate in a “walled garden”.Smart contracts can only receive information via messages from a publicblockchain address or another smart contract. Thus, the owner of thataddress has to first get the data from the public APIs and then pushthat data to the oracle smart contract. The issue is trust in the personwho pushes the data to the oracle as they would be able to push falseresults.

In one aspect, the smart contract runs on a public blockchain for thesmart contract. The multi-validator oracle can also include or be ablockchain based smart contract. The requested data can relate to abenchmark, a price feed, an exchange rate, etc. In one aspect, themethod includes validating and authenticating the information receivedfrom the public application programming interface.

The buyer, in addition to being able to close out the contract, can alsoperform a rebalancing. An example interface 900 for implementing anexample rebalancing option is presented in FIG. 9. The need forrebalancing arises in the context of a multi-asset portfolio in whichthe user may desire to change at least one asset's percentage or amountin the portfolio after it is created. When a user wants to change thecomposition of their portfolio, like adding or removing a coin, orchanging the weightings/percentages of a coin in their portfolio, theuser is able to use the same asset group to do so.

Interface 900 of FIG. 9 shows a current value 910, the current assets912, an option to change percentages 906, 908, and an option 902 tocomplete the rebalancing. An option 904 for accessing a rebalancinghistory can also be provided. When a rebalance occurs, a similar set ofcalculations takes place as when the user created the portfolio or wantsto settle the portfolio (e.g., a calculation of respective assetsamounts based on the prevailing rates from the exchanges coming from theblockchain asset data feed at that point in time, etc.).

A trustless multi-asset swap rebalancer is a set of functions programmedinto the blockchain-based smart contract 206 which allows for therebalancing of a portfolio of assets in accordance with the requirementsand demands of the owner of that portfolio. These assets exist via thetrustless multi-asset swap mechanism technology and the trustlessmulti-asset swap rebalancer is a component of that technology.

An example trustless multi-asset swap rebalancer process using interface900 can be as follows.

The buyer 202 decides which coins it would like to change in theinterface 900, and sends the new portfolio composition to the smartcontract as a signed message. The smart contract 206 calculates the newportfolio value, collateral, etc. based on oracle data 210 at that pointin time. The seller 204 takes a rebalancing fee to process this changeand accepts the new portfolio. The seller and buyer do not have to sendmore collateral if the rebalance is within the collateral limits for thecontract. If the user 202 rebalances to a large portfolio, the userwould need to add collateral to the contract. This is one of the reasonswhy in the aforementioned example, the system asks the user to send“excess collateral” to the smart contract at the creation of thecontract. This excess collateral can be used for future rebalances aswell as other purposes.

Both parties can confirm the rebalance data via a signed message, afterwhich the state of the portfolio is updated. The seller can change itsunderlying hedging portfolio accordingly to maintain the seller'sperfect hedge by buying or selling the mirror image of what the userbought and sold during the rebalancing of the contract.

The contract is written into the blockchain and thus onto the publicledger which may not be manipulated by any single party. When the userdecides to rebalance the contract, or the percentage of one or moreassets in the portfolio, that results in a state change. The new statechange is going to also be written into the blockchain. The new statechange cannot be erased or changed by any participant, and everyparticipant can see it.

When a user rebalances the portfolio, the rebalancing can result invarious scenarios. For example, if a user rebalances the portfolio tohave a higher value than its current portfolio value, then the userwould have to add incremental funds to the smart contract. In oneexample, assume a portfolio that started out as a 100 ETH valuedportfolio is rebalanced and in the rebalancing becomes worth 200 ETH.The buyer must put in an additional 100 ETH. The seller also must put inan additional 100 ETH. The amount added at the time of the rebalancingis that value above the current value of the portfolio (not the originalvalue).

The portfolio is fully collateralized. One of the risks in derivativesis that every participant is buying them on margin. If that margin getsexhausted, then problems arise. By contrast, the contracts disclosedherein are fully collateralized, which reduces the entire counterpartyrisk or trust in the system.

If the seller does not want to add more collateral, then the rebalancingwould not be established. If the user wants to change the allocation ofcryptocurrency and the value of the portfolio does not change, therebalancing can occur without additional collateral or approval from theseller. However, there could be mechanisms where if thresholds are met,then the seller would have to approve the rebalancing. For example, ifmore than 20% change in any asset is made, then the seller can berequired to approve. In another scenario, if the seller does not want toadd collateral, the buyer could go back to the marketplace and adifferent seller could buy into the rebalanced portfolio and theportfolio could end up with two sellers, each having a proportionalshare of the portfolio. However, if the seller is a business entity thatis servicing the portfolio sale requests, then those rebalancingrequests can always be met (within limits). Thus, such a business entitycould create the entire marketplace for such trades. The sellers can bemore like hedge funds and larger players or can provide a means for suchplayers to get access to the smart contracts disclosed herein. After theuser rebalances the portfolio, the process goes back to normal until theuser closes out the contract. The user can rebalance any number of timesbefore closing. At closing, as instructed by the buyer, the smartcontract calculates the result and sends the right amount to each party.

FIG. 10 illustrates an example method for rebalancing a multi-assetportfolio. The method includes establishing a multi-assetblockchain-based trustless smart contract for managing a multi-assetportfolio (1002), receiving an indication from an individual associatedwith the multi-asset portfolio of a desire to rebalance the multi-assetportfolio (1004), presenting the individual with an interface torebalance the multi-asset portfolio (1006), receiving, via the interfaceor some other means, input from the individual requesting a rebalancingof the multi-asset portfolio (1008), and updating the multi-assetblockchain-based trustless smart contract to yield a modifiedmulti-asset blockchain-based trustless smart contract which incorporatesthe rebalancing (1010).

Technically, the smart contract could be the same contract, existing inthe same place on the blockchain, but with a new “state”. That new statereflects the new composition of the portfolio which is recorded in theblockchain and is based on the rebalancing. The blockchain is thetransparent and relatively immutable record of state changes which thecontract undergoes. The system writes a new entry in the blockchain thatreflects the new portfolio composition. In another aspect, the systemcould create a new contract but with different parameters (assetallocations). The old contract can be discarded, deleted or madeinactive.

The indication of the desire to rebalance the multi-asset portfolio caninclude a request to rebalance one or more assets in the multi-assetportfolio or add/delete one or more assets in the multi-asset portfolio.The rebalancing of assets can involve a modification in a percentage oran actual number of coins (or real estate, or other asset). Theinterface allows the user to enter a number of coins or percentages withone or the other updated instantly based on the prevailing exchangerates and the current value of the portfolio. A user cannot rebalance toa greater amount of value than the current contract contains unless theuser posts additional collateral. Depending on what the rebalancingstructure is, the method can include receiving additional collateralassociated with the multi-asset blockchain-based trustless smartcontract to create the modified (or new) multi-asset blockchain-basedtrustless smart contract.

Typically, the individual is the buyer of the multi-asset portfolio.However, the individual could also be, in some scenarios, the seller,the management entity, some other third-party, or a combination ofindividuals or entities that, through some mechanism, agreed to arebalancing. The method can include receiving an authorization from aseller of the multi-asset portfolio for the rebalancing prior tocreating the modified/new multi-asset blockchain based trustless smartcontract.

The method can further include calculating at the multi-assetblockchain-based trustless smart contract an updated value to apply tothe new multi-asset blockchain-based trustless smart contract based ondata received from an oracle which provides real-time valuation data.The authorization received from the seller can include a signed messagewhich results in a change in state of the multi-asset blockchain-basedtrustless smart contract to yield the modified multi-assetblockchain-based trustless smart contract. As noted above, the modifiedmulti-asset blockchain-based trustless smart contract can be the samecontract but with the new data or parameters.

Referring to FIG. 11, an interface 1100 can enable social trading. Theinterface 1100 allows users to share their “portfolio” with theirconnections/friends in a social network. As illustrated, users can postmessages 1102 via interface 1100 which include links, addresses, and/orother information for sharing assets and/or portfolios between users inthe network. The user interface 1100 can be graphical, multimodal,speech-based, text based, graffiti based, or any combination of inputmodalities to achieve any function disclosed herein.

The social or social media aspect of this disclosure can also relate tothe leader-follower feature. The leader-follower mechanism is to reduceand eliminate the risk associated with any individual giving up custodyof one's wealth to another person or corporation who acts as a trustedthird party and whose goal is to make investments on behalf of theindividual. The system can insert or include certain authorizations intoa smart contract. Prior to the present disclosure, if people wantedsomeone to manage their investments, they go send their money to afinancial advisor or entity. Such entities have infrastructure to keeptheir investments safe. The follower-leader function allows oneportfolio buyer, who essentially has a contract, which is theirportfolio, to authorize another contract to do a specific thing—to sendmessages to their portfolio that tell it how to rebalance and tell itthe exact percentages and the weightings. The leader contract, however,cannot instruct the follower contract to settle, or sell collateral,etc. It is only allowed to send a message to the follower of portfoliosaying, for example: “I just rebalanced my portfolio and here are my newweightings and assets.” And then the follower portfolio automaticallyrebalances based on the leader adjustments. The leader portfolio neverhas to take custody of funds. This approach removes all the custodialrisk aspects. The messages can be delivered to one or more destinations,including other smart contracts, or any social media outlet.

Signed messages relate to data that is transmitted from one key toanother. The message is the data and the data can be anything (aninstruction to rebalance, for example, or an instruction to settle theportfolio). It is a signed message because the data is signed with theprivate key of the public key from which it is sent. In this case, thefollower portfolio has authorized the leader portfolio to send itmessages (e.g., the data of the new portfolio weightings and coins) andas long as the message is signed with the leader's private key, thefollower portfolio will change its own allocations to that of theleader. Thus, as a security feature, smart contracts which interact witheach other or with their users can do so through signed messages toprovided authenticated data transmission.

The example above discusses implementation of asymmetrical cryptography(i.e., Public key cryptograpy) for secure or authenticated datatransmissions. This example cryptography implementation is provided as anon-limiting example for the purpose of clarity and explanation. Itshould be noted that other encryption/cryptography configurations andtechniques, such as symmetric-key algorithms, can also be implementedand are contemplated herein.

The reference in FIG. 11 is to Twitter. However, the principlesdisclosed can apply to any social media environment. For example,Facebook, Pinterest, Instagram, SnapChat, blogs, and so forth, aresocial networks through which individuals can share their portfolios.The individual functionality of these and any other social media areincorporated herein and applicable to the general concept of receiving aposting of a social media object from a user which includes a button, ahyperlink, or other type of interactive feature which points recipientsof the posting to a portfolio of the user. Steps which must beimplemented in order to enable recipients of the posting to interactwith the posting and thus initiate a following within a recipientportfolio of the posting entities leader portfolio can occur in variousways.

Posting to social media can allow people to “find” a smart contract, andauthorize that smart contract to serve it rebalancing instructions. Theinterface 1100 for such a process can be implemented in a variety ofplatforms and computer programming languages, such as web-based (e.g.,HTTP or HTTPS), mobile or native applications, etc. Following aportfolio allows the user to create their own marketplace (PRISM) butalso allow the leader to do portfolio allocation decisions for the user.In some cases, this can involve two aspects or processes, which can runsimultaneously. One is the front-end process which displays the contractdata for the user, which can reside on the blockchain in what is calledbytecode, and the second is the actual smart contract itself, which canrely on other technologies. In some examples, the front-end can be“read-only” for a smart contract data runs on the blockchain.

For example, a social media site may communicate via APIs or other meanswith portfolio management entities in such a way as the posting entityand the recipients can remain within the social media site to confirm atransaction associated with one portfolio following another portfolio.Transaction confirmations happen via the blockchain. The social platformcan generate or hold keys for users to initiate a transaction securely.In some cases, a social media site can be modified to function as aclient-side encrypted wallet (e.g., ETH wallet) and support suchfunctionality.

In some aspects, a posting to a social media site can include ahyperlink which opens a new webpage when activated by the user, such asthe marketplace webpage. Users of the marketplace can initiatetransactions using a wallet (e.g., ETH wallet), such as Mist,MyEtherWallet.org, or any other wallet. In some configurations, when auser uses the marketplace, the client device of the user may have aseparate window or tab open which can be the user's wallet. The walletcan store the private keys the signed message(s) can thus originate fromthat wallet. In this regard, another aspect of this disclosure can be ablending of an interface with a wallet interface which stores, presents,and/or provides access to the necessary private keys within a socialmedia network site or environment. Thus, from a user's perspective, theuser appears to remain within the social media site, but will also haveaccess to the services available through the user's wallet.

Third-party entities can also aid in the integration between the socialmedia site and the portfolios of the posting entity and the followingentity. This disclosure covers processing from the standpoint of any ofthese entities including the portfolios themselves. Thus, thetransmitting, data, and/or coordination of data or information can beclaimed herein from the standpoint of a social networking site, a thirdparty, a portfolio, etc. Individual entities can also provide particularsteps to affect at least a part of the process as well.

In some respects, the leader/follower functionality can function likeprogrammed money. It is money that cannot be told to do bad things. Inthe hedge fund world, there can be solvency issues and audits, and thereis no way around these issues as of now because of how investments arehandled: Hedge funds need to take the custodianship of the funds. Withthe leader/follower approach disclosed herein, the user (1) Never givesownership of the funds to the seller, (2) Never has to worry about thesettlement calculation, and (3) Can get the information directly from aprofessional, the leader in this case. The program in the smart contractonly is allowed to give the instructions of rebalancing.

The follower in some cases could be given options to accept the leader'srebalancing, or to further adjust the rebalancing and then apply it tothe follower's own portfolio. Market research could be provided at thispoint to the follower. For example, the 1 year or 1 month percentages ofthe performance of the assets in the rebalancing could be presented tothe follower before accepting the rebalancing. Followers could alsoprogram or require certain parameters or triggers that are automaticallyimplemented. These can relate to performance, performance history,boundaries on variation in the rebalancing, thresholds on additionalcollateral needed, limits on percentages of certain assets in theirportfolio, a percentage of how much of the rebalancing to accept (e.g.,I will follow 50% of the changes of the leader) and/or the like. Theparameters may involve timing, such as implementing the rebalancing 1week after the leader rebalances and with the authorization of thefollower. In this way, the follower could see the performance of therebalancing before following.

The use of blockchain and smart contracts herein can provide significantadvantages over a robot-type advisor. For example, with a robot advisor,the user is still giving their money to a third party to manage. Use ofa third-party custodian of the money can create various risks aspreviously explained. However, the smart contracts and rebalancingperformed on the blockchain herein eliminates the risks of using athird-party custodian of the money.

The use of blockchain and smart contracts herein also providesignificant advantages over use of brokers, and reduces risks associatedwith using brokers. For example, assume a broker has an algorithmictrading system that is a computer program that buys or sells assets.With the broker, the algorithmic trading system, and thus the computerprogram, is hosted and/or owned by the broker. The computer programinstructs the broker's system to make trades on specific market(s) basedon funds that the broker has taken custody of. By contrast, in theapproaches herein, the blockchain is a computer program that is nothosted on systems owned by the broker or any single entity. Moreover,the smart contract algorithm is provided by computer code in theblockchain (e.g., Ethereum blockchain or any other blockchain). Theblockchain is not owned by any single entity. The blockchain does nottake custody of the funds, as the funds “exist” on the blockchain. Thus,it separates the custodial aspects from the investment manager. Thefollower still has to trust the leader's investment decisions, but thefollower does not have to trust the leader's custodianship of the money.

FIG. 12 illustrates an example interface 1200 for accessing portfolioinformation and features. In this example, the interface 1200 canprovide a summary section 1206 with a summary of the portfolio for theuser. The interface 1200 can include a clone option 1202 to allowcloning of the portfolio. For example, the clone option 1202 can triggera cloning operation, which can provide an opportunity for a user, suchas a friend or acquaintance, to clone the portfolio.

The interface 1200 can also include a follow option 1204. The followoption 1204 can be selectable to allow a user to automatically rebalancewhen the owner rebalances the portfolio. The follow option 1204 canallow a user to follow changes made to another portfolio of choice.Thus, users can copy, clone, and/or follow one or more portfolios viainterface 1200. A trustless leader-follower application enables amechanism which automatically “copies” or “mimics” the actions of onetrustless portfolio onto another, without the former taking custody ofthe latter.

One of the challenges addressed by the leader-follower applicationinvolves the issue that many investors either lack the ability or timeto determine what assets are good investments. Such assets could includestocks, bonds, digital currencies, blockchain assets, commodities, andmany other types of assets. Therefore, many individual investorsoutsource the management of their investment decisions (and theexecution of investments) to the professional asset management industry.This can include financial advisors, hedge funds, mutual fund managers,and many other types of investment managers.

Here is a simple example of where that will be helpful with basicallynon-digital assets, stocks or bonds. A lot of the regulation that existson a national basis does not allow people to buy foreign stocks unlessthey are listed on a certain exchange using an ADR, or AmericanDepository Receipt. This is essentially a reflection or a listing ofthat stock in the American markets. If a person wants to buy small ormid-cap stocks or some other esoteric asset in another country orjurisdiction, the amount of inefficiency and cost that the person isgoing to face in doing so is large. There are also limits on the amountthat the person can buy. However, with the blockchain-based smartcontract approaches and concepts disclosed herein, the technology couldenable an easy purchase of such foreign assets. The disclosed conceptscan enable micro payments with great fluidity of value transfer on aglobal basis, as well as significant freedom, lower costs, and highersecurity.

When individuals deposit their money with financial firms, they areexposed to a well-known set of risks. One of those risks is custodialrisk, defined by the fact that the individual is no longer in possessionof their own funds and has elected another legal entity—the firm—to bethe custodian of those funds. This decision creates a risk for thecustomer because the custodian could intentionally or unintentionallylose/steal those funds. Historically, some of the ways custodians havelost customer funds include but are not limited to: (1) fraud; (2)negligence of the custodians; (3) improper or erroneous accounting(either intentional or unintentional); and/or (4) domiciling of thosefunds in high risk country which seizes those funds for politicalreasons. This is why a firm's reputation, track record, physicallocation, type of fund, and other factors play an important role in theasset management and investment industry.

Individuals must choose whom to “trust” as the custodian of their funds.Often, it can take decades for a firm to build trust and develop a “goodreputation”. However, this trust comes with a cost. The cost is anentire array of infrastructural processes designed to prove to others(clients, regulators, employees, etc.) that they are acting in goodfaith as custodians of their clients' money. Some of thoseinfrastructural items include but are not limited to: (1) regularaccounting and audits by reputable firms, (2) a corporate governance andlegal structure designed to both adhere to local regulations andproperly incentive the management, and/or (3) building up a track-recordwithin the industry of competence, integrity, and good will. Reducingand even eliminating the cost of this trust is achieved with theleader-follower aspect of this disclosure.

When one user follows another user's portfolio, that user authorizes theuser's portfolio to receive “rebalancing” instructions from the otheruser's portfolio; that is, one user is the follower and the other useris the leader. The leader portfolio is only authorized to sendrebalancing instructions to the follower portfolio and not, for example,ask the contract to settle, remove the collateral from the contract,change the settlement address, or a whole number of other actions thatare reserved just for the follower. There may be any number ofparameters or functions that can be programmed into the contract thatthe followers can follow. Functions can include, for example, when toclose the contract based on the leader functions performed. Theleader-follower functionality can be a feature programmed into the smartcontract 206. The leader-follower mechanism is a set of functionsprogrammed into a blockchain-based smart-contract that allow thefollower portfolio to receive instructions from the leader portfolio.One example of instructions can include cryptographically securemessages sent via a blockchain network from the leader's portfolio tothe follower's portfolio. These messages contain the information for thefollower's portfolio to rebalance to match that of the leader'sportfolio, without the leader ever taking custody or being able to seizethe funds of the follower. In other aspect, the leader could be enabledwith the ability to not just send messages but also change followerportfolios. For example, once the leader has made a change, the marketconditions might not be exactly the same when the follower wants to makethe similar adjustment. The leader could cause the follower to make aless risky change than performing the exact mirror adjustment as theleader did. The leader's change might adjust the marketplace immediatelywhich might put the followers in a less advantageous position than theleader.

Blockchain asset portfolio information from various users can be used tocreate leadership tables and rankings. For example, the system can useportfolio performance information to post leaderboards on a daily,weekly, monthly and/or yearly basis. FIG. 13 illustrates an exampleinterface 1300 of a leaderboard. Leaderboards can allow users to“follow” specific “portfolio managers” with just a few clicks asdescribed above.

Interface 1300 can display portfolio owners 1302 and portfolio data1304, 1306, 1308, 1310, 1312 for corresponding portfolios. The portfoliodata 1304, 1306, 1308, 1310, 1312 can include, for example, one or moreportfolios or portfolio descriptions, a portfolio return value, aportfolio weekly return value, a portfolio monthly return value, aportfolio yearly return value, etc. The portfolio data 1304, 1306, 1308,1310, 1312 can pertain to a single portfolio associated with arespective owner or a group of portfolios associated with the respectiveowner. Moreover, a portfolio associated with the portfolio data 1304,1306, 1308, 1310, 1312 can include multiple assets, which can behomogeneous assets (i.e., same type of assets) or heterogeneous assets(i.e., different types of assets).

In some cases, the portfolio data 1304, 1306, 1308, 1310, 1312 caninclude more or less information, such as asset information, portfolioparameters, etc. The portfolio owners 1302 and/or portfolio data 1304,1306, 1308, 1310, 1312 can be user-selectable. Thus, users can select aparticular field or value to interact with that field or value. Forexample, in some cases, users can select a user from the portfolioowners 1302 to clone or follow the portfolio associated with that user.Thus, a user can review the portfolio owners 1302 and portfolio data1304, 1306, 1308, 1310, 1312 and select portfolios to follow or clonebased on the data provided in the interface 1300.

The portfolio data 1304, 1306, 1308, 1310, 1312 can also be selected bya user to drill down on the associated data. For example, portfolio data1304 can display a portfolio or portfolio description of a respectiveowner. The user can select the portfolio data 1304 to view additionaldetails about that particular portfolio, such as portfolio parameters,user preferences, portfolio statistics, portfolio assets, followinginformation (e.g., how many users are following that particularportfolio, which users are following that particular portfolio, commentsprovided by users regarding that particular portfolio, etc.), notes fromone or more users pertaining to that particular portfolio, portfoliohistorical data, etc.

The portfolios presented in the interface 1300 can be ranked ororganized based on one or more factors, such as performance statistics,ratings, number of followers, consistency, type of assets, averages, orvalues associated with the portfolio data 1304, 1306, 1308, 1310, 1312.For example, the portfolios can be listed in order of performance basedon one or more performance factors. As another example, the portfolioscan be listed according to user rankings. In some cases, users canfilter which portfolio owners 1302, portfolios, and/or portfolio data1304, 1306, 1308, 1310, 1312 to view on interface 1300. For example, auser can filter interface 1300 to only display friends of the user(e.g., other users having a relationship or contact with the user), aselected list of users, a top number of users, users associated with aparticular organization, users in a particular geographic location, etc.The user can also filter the interface 1300 based on other parameters orfactors. For example, the user can filter the interface 1300 to onlydisplay portfolios having certain assets, portfolios that are older thana specific period of time.

The leader/follower feature enabled by interface 1300 can allow users toapply different investment research processes to portfolio design andconstruction. For example, a user could create the following exchangetraded fund (ETF)-like blockchain asset product: A market cap weightedportfolio of the top ten blockchain assets by market cap. Such aportfolio is like the Dow Jones of blockchain asset investments. Itwould automatically rebalance over some period for which a user couldchoose. The user could also create a version with the top twenty coinsor the top 50 coins. Users could back-test and publish results ofdifferent portfolio compositions. This could also work for an inversemarket cap ETF or for making a portfolio allocation that optimizesreturn vs volatility using modern portfolio management techniques. Aleaderboard can present one or more of the following data: a pie chart(or other graphic) illustrating a distribution of assets, an owner, aportfolio name, a percentage of returns on a lifetime basis, weeklybasis, monthly basis, yearly basis, or user-selectable basis. A userinteraction with one of the portfolios (such as on a pie chart graphic)can return a detailed accounting of the assets and the percentage of theportfolio that has that respective asset.

In this way, users could create investment strategies and publishresearch which supports their portfolio composition, and share theirportfolios for other users to follow. The leader/follower feature alsoenables other applications. For example, a user can employ a specificpattern to significantly reduce the chance of a hack on the private keyof the user's portfolio while maintaining the flexibility to trade thatportfolio from an “insecure” computer or network. The user can create a“hot” leader portfolio which has a negligible amount of value in it, forwhich the private key can be exposed carelessly. That “hot” portfoliowould be the leader to the same user's “cold” portfolio which holds themain value of the portfolio, say $30 k or 40 k worth of digital assets.The private key to this “cold” portfolio would be generated in a secureenvironment and put in cold storage for the life of the portfolio. Sincethe hot/leader portfolio is only authorized to rebalance thecold/follower portfolio then if the “hot” key was compromised, the worstthat an attacker could do is simply rebalance the user's hot portfoliobut never steal the funds in the user's cold portfolio.

In other examples, active trading of portfolios can be provided by thoseskilled in such endeavors on behalf of those with limited skills. Forexample, assume a user has a friend who has had a lot of success tradingand asset management. However, the user is wary to let the friend tradea large number of coins due to legal, custodial, and/or accountingrisks. With this approach herein, the user can just follow that thefriend's portfolio without any of those risks, as the user retainscontrol and does not relinquish custody of assets to the friend or anyother third party.

In some cases, non-crypto assets can be provisioned by adding new oracledata feeds. For example, by connecting this technology to a Bloombergterminal and corresponding execution infrastructure at a broker-dealer,hedge fund, investment bank, etc., different types of non-crypto assetscan be provisioned as or for portfolios. To illustrate, users can addgold or other precious metals to their trustless portfolios. In such anexample, those real-world assets could act as a trustless entry and exitmechanism for selling off entire exposures of blockchain assets shouldthe user choose to do so. For example, the user liquidates an entireportfolio and moves to gold directly within their trustless portfolio onthe blockchain. All of this is profound in that the system can have“fully reserved” digital assets collateralized with blockchain assetssuch as Ethereum.

The global derivatives industry is vast with over a quadrillion dollarsin outstanding contracts and hundreds of different types of derivativeslike swaps, options, CDS, exotics and many more. In the traditionalfinancial system, almost all consumer and business financing activitiesare in some way attached to a financial derivative, whether that be acredit card or mortgage (CDS and interest rate swaps), activities in theCFO's office of a fortune 500 (FX currency swaps and futures), or thetrading operations at a large exchange (risk management and hedging).This branch of financial engineering can be combined with the disclosedblockchain technologies and smart contracts to produce consumerfinancial products that cost less, eliminate intermediaries, increasesecurity, and provide entirely new services, such as the trustlessportfolio service described herein.

The smart contract disclosed herein can apply to any contracts (e.g.,legal contracts, insurance contracts, etc.). For example, the smartcontract described herein can be applied to insurance contracts,business contracts, intellectual property licenses, specific performancecontracts, assignments, buying or selling a product or services, and soforth. Indeed, the procedures, components and systems disclosed hereincould apply to any kind of contract. Any kind of blockchain technologycan also be implemented or combined with the concepts disclosed herein.In fact, the technologies disclosed herein are blockchain agnostic andcan be implemented with any future blockchain technologies.

FIG. 14 illustrates an example method for leader/follower approach. Amethod includes establishing a multi-asset blockchain-based trustlesssmart contract for managing a multi-asset portfolio (1402), insertinginto the multi-asset blockchain-based trustless smart contract anauthorization for a leader multi-asset blockchain-based trustless smartcontract to send messages from the leader multi-asset blockchain-basedtrustless smart contract to a follower multi-asset blockchain-basedtrustless smart contract regarding a leader rebalancing of the followermulti-asset blockchain-based trustless smart contract (1404), andmodifying the follower multi-asset blockchain-based trustless smartcontract based at least in part on the leader rebalancing of the leadermulti-asset blockchain-based trustless smart contract (1406). Themodifying of the multi-asset blockchain-based trustless smart contractcan include an automatic follower rebalancing of the multi-assetblockchain-based trustless smart contract that matches the leaderrebalancing.

The modifying of the leader multi-asset blockchain-based trustless smartcontract can include a follower rebalancing of the multi-assetblockchain-based trustless smart contract that follows a portion or asubset of the leader rebalancing. For example, the system could includevarious rules, policies, constraints, and so forth, which a followercould implement such that upon a leader rebalancing a leader portfolio,a policy could be implemented which compares the rebalancing to thepolicy. In some cases, the policy may require that there is no change toone particular asset in the follower portfolio. If the leader portfoliochanged the percentage of that particular asset in the leader portfolio,then the follower portfolio can evaluate the changes, apply the policy,and implement a rebalancing that is not exactly the same as the leaderportfolio but implements aspects or principles set forth in the leaderportfolio. In other cases, however, the follower may have the option toapply the rebalancing with the change to the particular asset. Forexample, the follower can approve such modification or include one ormore policies or conditions for approving such modification.

To illustrate, the leader portfolio may have doubled a percentage of asecond asset in the portfolio, as well as doubled a first asset. Thepolicy may require no change in the allocation of the first asset. Thus,the follower portfolio may increase the balance of the second asset by150%, rather than the doubling as occurred in the leader portfolio. Thepolicy may require that the rebalanced follower portfolio have the sameoverall market value is the leader rebalanced portfolio and thusimplement similar changes to those of the leader, although in differentproportions, to arrive at the same overall market value. There are otherscenarios which can be contemplated in how to structure a policy whichwould be evaluated against a leader portfolio change. Parameters whichcan be implemented in such a policy can include an overall portfoliovalue, percentages above or below and overall rebalanced portfoliovalue, parameters associated with individual assets, parametersassociated with timing, such as when to implement a rebalancing, or howto implement portions of a rebalancing over time, parameters associatedwith external data which can be accessed and evaluated to confirmwhether to follow a leader portfolio or whether to decline to follow,personal profile data, social networking data from individuals and/orsocial networking connections, a level of a social networkingconnection, and so forth. The embodiments in this regard can be claimedfrom a leader perspective of transmitting the leader changes to one ormore followers, or could be claimed from the follower perspective interms of receiving the leader information, and making adjustmentsaccordingly.

The leader multi-asset blockchain-based trustless smart contract cansend rebalancing messages to the follower multi-asset blockchain-basedtrustless smart contract. The method can include receiving market dataat the multi-asset blockchain-based trustless smart contract prior tomodifying the multi-asset blockchain-based trustless smart contract suchthat the modifying takes into account both the market data and theleader rebalancing. In one aspect, the multi-asset blockchain-basedtrustless smart contract is modified for a percentage of the leaderrebalancing. Further, there can be timing variations to the process. Themethod can include modifying immediately or in a predetermined timeafter receiving the leader rebalancing. There can also be events andconditions implemented in the process. For example, the method caninclude modifying the smart contract upon occurrence of a specificevent, such as a user input or a triggering condition. In anotherexample, if the follower receives the data late, such that the markethas adjusted to a large leader modification, then the follower can takeinto account the current market conditions, the timing, and so forth toimplement the same change or a variation thereof.

FIG. 15 illustrates an example interface 1500 for selling a portfolio ofassets. The interface 1500 can include a summary view 1502 which candisplay assets 1510 and corresponding asset data 1512. Example assets1510 can include, without limitation, Litcoin, Ripple, Ethereum, Dash,Bitcoin, and/or any other crypto and non-crypto assets. The asset data1512 can include an initial value (e.g., value at time of purchase), acurrent value, a percent of the total portfolio investment or value, acurrent rate, a performance (e.g., gain, loss, etc.), and so forth.

The interface 1510 can also include a liquidation details area 1506which can indicate one or more assets from the assets 1510 being sold,purchased, traded, etc., an amount of the one or more assets being sold,purchased, traded, etc., an address or party involved in the liquidationtransaction (e.g., buyer, seller, etc.), as well as other informationassociated with the transaction, such as comments or preferences. Theinterface 1510 can an address 1504 associated with the liquidationdetails. For example, the address 1504 can identify the address wherethe smart contract should send the assets.

The interface 1510 can include a control element 1508 configured totrigger or execute the liquidation when activated by a user. Forexample, the control element 1508 can be a button that the user canselect to liquidate the portfolio presented or selected, initiate theliquidation operation, accept the liquidation operation, and/orotherwise complete the liquidation operation. The smart contract, uponthe buyer liquidating the portfolio, calculates the various amounts thatare to go to the respective buyer and seller and carries out theliquidation operation based on the calculated amounts and the smartcontract instructions.

The interface 1510 can allow a user to liquidate an entire portfolio ora selected subset of assets in the portfolio. In some cases, theinterface 1510 can also allow the user to liquidate a group ofportfolios. The user's specific preferences vis-à-vis which assetsand/or portfolio(s) to liquidate can be specified via the liquidationdetails area 1506, for example.

FIG. 16A illustrates an example method for asset management inaccordance with various aspects of the present technologies. The examplemethod in FIG. 16A focuses on the operations of the smart contract, asopposed to the separate operations of the oracle, rebalancing component,leader/follower component, and so forth.

In this example, the method includes receiving, from a buyer and at asmart contract, an identification of a portfolio of assets (1602).Blockchain assets are one example of such assets. Insurance contract,stocks, bonds, commodities, real estate, intellectual property, legalcontracts, etc., are examples of other types of assets. The portfoliocan include various types of assets, including various types ofblockchain and/or non-blockchain assets. Moreover, the smart contractcan be implemented in a blockchain, as previously described. Theidentification of the portfolio of assets can include a respectivepercentage of each type of asset to enter into the portfolio of assets.

The method includes receiving, from the buyer, an amount that the buyerwill invest in the portfolio of assets (1604). The amount can be anyamount specified by the buyer for investing in the portfolio. The amountthe buyer will invest can include the current value of the assets. Insome cases, the amount can be in cryptocurrency, such as Bitcoin orEthereum.

The method includes receiving, based on one or more exchange rates(e.g., prevailing rates) and the amount being invested by the buyer, anumber of assets in the portfolio of assets (1606). The number of assetscan be the number of assets in the portfolio as calculated based on theamount the buyer is investing and the one or more exchange rates.

The method includes receiving a confirmation from the buyer of theportfolio of assets having the number of assets (1608). The confirmationcan indicate that the buyer agrees with or validates the portfolio withthe number of assets. The method includes and calculating, by an entity,a cost of the portfolio of assets to yield a contract (1610). The entitycan be, for example a seller of the portfolio of assets.

The method further includes receiving the amount and/or excesscollateral from the buyer as a buyer acceptance of the contract (1612).For example, the method can include receiving the amount invested by thebuyer and excess collateral as a buyer acceptance of the contract.Moreover, the method includes receiving an entity acceptance of thecontract by receiving an entity amount at the smart contract (1614). Theentity can sign the entity acceptance using one or more entity signaturekeys for the contract, which can include, for example, private keys of asending address associated with the entity.

In some cases, after receiving the entity acceptance, the method caninclude the entity purchasing the underlying assets that make up theportfolio of assets from one or more exchanges and holding theunderlying assets.

The method includes receiving, at the smart contract, an indication thatthe buyer wants to close the contract (1616). The buyer can send theindication to the smart contract to initiate the closing of thecontract. In some cases, the buyer can sign the indication or a messageincluding the indication. For example, the buyer can send the indicationvia a message signed by the buyer using a buyer private key. The methodthen includes settling the contract via the smart contract based on acurrent value of the portfolio based on pricing data received from atrusted valuation entity (1618). The settling of the contract can betriggered by the indication that the buyer wants to close the contract.Thus, the buyer can control the settlement of the contract and requestthe settling when desired by the buyer. The current value of theportfolio can be calculated based on pricing data received from atrusted valuation entity. The contract can also be closed by othertriggers besides just the buyer decision.

In some cases, a private key can hold the entire portfolio through thesmart contract. Moreover, there is no need for multiple wallets tomanage multiple blockchain assets. Thus, the buyer can manage theportfolio containing various types of blockchain assets without havingto maintain a respective wallet for each type of blockchain asset.

Settling the contract via the smart contract can include calculating,via the smart contracts, the current value of the portfolio andcalculating a collateral amount and resulting proceeds to be sent to thebuyer and the entity. The method can include sending a first resultingvalue from the resulting proceeds to the buyer and a second resultingvalue from the resulting proceeds to the entity. In some examples, thefirst resulting value can represent an original investment amount, plusa profit, plus an original excess collateral amount, and/or minus acommission. The second resulting value can include a difference from theoriginal investment amount, minus a loss, plus the original excesscollateral amount, and/or plus the commission.

In some cases, after receiving, at the smart contract, the indicationthat the buyer wants to close the contract, the entity can sell theportfolio of assets on an exchange. Moreover, in some cases, prior toreceiving, at the smart contract, the indication that the buyer wants toclose the contract, the method can include receiving a rebalancingrequest which indicates that the buyer wants to rebalance the portfolioof assets. The method can include receiving a new portfolio compositionfrom the buyer based on the rebalancing request, calculating a newportfolio value and a new collateral value based on the new portfoliocomposition and data from the trusted valuation entity and accepting thenew portfolio composition by the entity.

As part of this process, the method can include determining whetheradditional collateral is needed according to a collateral limit for thecontract and receiving a confirmation of the new portfolio compositionby the buyer and the entity. In some examples, the confirmation can bereceived via a buyer signed message from the buyer and an entity signedmessage from the entity. In some cases, the entity can buy or sell amirror image of what the buyer bought and sold during a rebalancing ofthe contract.

FIG. 16B illustrates another example method for asset management inaccordance with various aspects of the present technologies. The methodincludes receiving, from a buyer, an identification of a portfolio ofassets associated with a blockchain-based smart contract (1620),receiving, from the buyer, an amount to invest in the portfolio ofassets (1622) and determining a number of assets in the portfolio ofassets based on one or more asset exchange rates and the amount toinvest received from the buyer, to yield a composition of the portfolioof assets (1624).

In response to receiving, from the buyer, a confirmation for thecomposition of the portfolio of assets, the method includes calculatinga cost of the portfolio of assets based on the composition of theportfolio of assets (1626), determining a portfolio contract based onthe cost of the portfolio of assets (1628), receiving, from the buyer, abuyer acceptance of the portfolio contract, the buyer acceptancecomprising the amount to invest and excess collateral (1630),identifying an entity acceptance of the portfolio contract in responseto receiving, at the blockchain-based smart contract, an entity amountassociated with the portfolio contract (1632) and receiving, at theblockchain-based smart contract, an indication that the buyer hasrequested to close the portfolio contract (1634).

In response to the indication that the buyer has requested to close theportfolio contract, the method can include settling the portfoliocontract via the blockchain-based smart contract based on a currentvalue of the portfolio of assets, the current value of the portfolio ofassets being based on pricing data from a trusted valuation entity(1636). The portfolio of assets can include blockchain assets to yield aportfolio of blockchain assets. The identification of the portfolio ofblockchain assets can include a respective percentage of each type ofblockchain asset to enter into the portfolio of blockchain assets. Theamount to invest can include an amount of at least one of Bitcoins,Ethereum, a cryptocurrency, and another blockchain asset. The amount toinvest can also include a first amount in a currency or a second amountrepresenting a physical asset. The acceptance can be associated with anentity, the entity being a seller of the portfolio of assets. Settlingthe portfolio contract can include calculating, via the blockchain-basedsmart contract, the current value of the portfolio of assets, acollateral amount, and resulting proceeds to be sent to the buyer and anentity associated with the entity acceptance. The resulting proceeds caninclude a first resulting value and a second resulting value. In thisregard, the method can further include sending the first resulting valueto the buyer and the second resulting value to the entity, the firstresulting value including an original investment amount, plus a profit,plus an original excess collateral amount, and minus a commission, andthe second resulting value including a difference from the originalinvestment amount, minus a loss, plus the original excess collateralamount plus the commission.

The method can further include, after receiving the indication that thebuyer has requested to close the portfolio contract, selling theportfolio of assets on an exchange. The method can also include, priorto receiving the indication that the buyer has requested to close theportfolio contract, receiving a rebalancing request indicating that thebuyer has requested to rebalance the portfolio of assets, receiving anew portfolio composition from the buyer based on the rebalancingrequest, calculating a new portfolio value and a new collateral valuebased on the new portfolio composition and data from the trustedvaluation entity, accepting the new portfolio composition by an entityassociated with the entity acceptance of the portfolio contract,determining whether additional collateral is needed according to acollateral limit for the portfolio contract and receiving a secondconfirmation of the new portfolio composition by the buyer and theentity via a buyer signed message from the buyer and an entity signedmessage from the entity.

The method can further include providing, to the entity, a rebalancingfee prior to the accepting of the new portfolio composition by theentity. The entity can buy or sell a mirror image of assets bought andsold by the buyer during a rebalancing of the portfolio contract.

The indication that the buyer wants to close the contract can bereceived via a signed message from a buyer private key, and wherein theentity acceptance is received along with entity signature keyscomprising private keys of a sending address of an entity associatedwith the entity acceptance.

The disclosure turns to a discussion of various security aspects of theapplication and approaches herein, an example history of attacks ondecentralized approaches and example remedies and improvements includedherein.

The disclosure will reference code documentation as well as informationabout smart contract security and best practices. After the well-knownattack on the decentralized autonomous organization (DAO) on theEthereum block chain in June 2016, many Ethereum users both old and newwill have an increased skepticism about the security of decentralizedapplications built using smart contracts. Smart Contract technology isin its early days and the DAO hack, although unfortunate and difficult,was a wake-up call for smart contract developers to approach applicationdesign from a new perspective. It also showed that the underlyingprotocol did not experience a game-ending failure during this time ofdistress; an observation that should be comforting to those makinginvestments in this platform.

In many ways the product and technology disclosed herein (PRISM) is theopposite of the DAO. The DAO had a very large amount of Ether in asingle contract; whereas in PRISM, the product can hold small amounts ofEther (1 k to 50 k USD) in a single contract. In the DAO, there werethousands of individuals authorized to interact with a single smartcontract; in contrast, with PRISM, there are two individuals (the buyerand the seller) and the oracle that are authorized to interact with eachcontract (and there will likely be thousands of contracts rather thanjust one). In the DAO, the contract was supposed to have a considerablelife span (many years); whereas in PRISM, the product for each contractcan be short-lived and disposable (e.g., from weeks to months forexample). These considerations and others create a significantlydifferent risk profile for the PRISM product when compared to the DAO.The risk profile and risk management approaches herein providesignificant security checks and safeguards.

In one example remedy, a risk analysis can be applied to a contract inwhich steps are taken over time as a risk of a DAO type of attackincreases to encourage completion of the contract with increasingintensity. For example, reminders could be sent to the seller withsingle click types of interactions to encourage the seller to close outthe contract. Initial reminders could include more interactions tocomplete the process (such as three clicks in the security code) andlater prompts to provide a more simplified interaction to close out thecontract inasmuch as the risk factor has increased to a certainthreshold.

The disclosure next addresses a risk assessment framework andmethodology for decentralized applications. In this security analysis,the disclosure will separate the different sources of risk along thetechnology stack based on the root causes of those risks. This will helpdevelop a framework for identifying, discussing, and managing theserisks throughout the document. There are risks associated with using theSolidity Language. This includes risks derived from known and unknownbugs, faults, and/or issues with the Solidity programming language.

For example, it is the goal of PRISM to reduce Solidity risks bychanging the code-base to reflect new smart contract development. Thereis a risk associated with using the Ethereum blockchain. This is therisk derived from the attributes of the Ethereum blockchain itself. Thisincludes potential attacks on the protocol, hard-forks, communitydisagreements, consensus algorithm weaknesses, and more. There is a riskassociated with Crypto Primitives. This is the risk derived frompotential weaknesses in the fundamental hard-cryptographic primitivesthat secure such protocols. Things like any known or unknownweaknesses/attacks/constraints in SHA256, ECDSA, TLS, etc. There is arisk associated with Business and Operations. This is the risk derivedfrom the interaction of a centralized organization with the PRISMapplication and service. There's also risk associated with markets andvolatility. This is the risk derived from rapid changes in the marketvalue of either a single digital asset or a portfolio of digital assets.This risk is derived from the unpredictable nature of blockchain assettrading and includes the aforementioned Black Swan risks. Further risksrelate to an Exchange Custodial risk. This is the risk derived from theobservation that almost every exchange in the blockchain asset tradingworld is largely a centralized custodian of funds with almost notransparency into their solvency, audits, operational processes, etc.Finally, there is an Application Architecture Risk. This is the riskderived from how the application is fundamentally architected in termsof what actions parties are authorized to take via contract rules. Forexample, in PRISM, if the leader is authorized to change the settlementaddress of the follower's portfolio, this could create a security riskand vulnerability in the application.

The application next addresses remedies for some of these risks. Thedisclosure will begin with the Application Architecture Risk. One of themost common attacks results when an entity managing the contractsassumes the role of both portfolio seller and oracle. Creating“trustless” oracles is a topic in Ethereum and the overall discussion ofsmart contracts, so this discussion goes hand-in-hand. In aconfiguration where the managing entity is both the seller and theoracle, there are a number of attacks which could be launched by eithera nefarious party or a hacker that gains control over the entity'sprivate keys to the portfolio seller contract or the oracle. Below is anexample attack which could be launched.

A fraudulent settlement attack which would push false data to the oracleis possible. In the case of a nefarious party, when the portfolio buyerasks to settle a contract, the nefarious party would push erroneous datato the oracle (like coin prices equal to zero) so that the portfoliovalue is zero, and subsequently all the collateral gets pushed to thenefarious party (the portfolio seller address in the contract). Thisequates to nefarious party stealing the user's funds.

The minimum viable product (MVP) was constructed under the assumptionthat since token pricing data is so public and transparent that if thenefarious party did this attack, it would be detected very quickly, andsubsequently word would spread quickly, and consequently the nefariousparty's business would be ruined. As previously noted, in the approachesherein, only the portfolio buyer can initiate settlement and so thenefarious party would have to wait for each portfolio buyer to ask tosettle the contract before pushing false data. Such an attack would bedetected quickly. In this scenario, the nefarious party could deceive ahandful of customers and earn double their initial collateral deposit,but subsequently discourage any future users of the product. Withsmaller portfolios ranging from 1 k to 50 k dollars or ETH, the expectedvalue of this attack is relatively low considering the upfrontinvestment by the management entity to build the product in the firstplace (larger than multiples of 50 k). A nefarious party would be muchwiser attempting to settle all outstanding contracts simultaneouslybased upon fraudulent settlement data rather than a handful of customersone-by-one as they come in to settle their portfolios. In this way, thenefarious party would be making “one big grab” for all users' fundsexisting in all outstanding contracts simultaneously. However, with theapproaches herein, the nefarious party cannot settle all outstandingcontracts simultaneously since only the buyer can initiate settlement.

In one example of the MVP (Prism. sol), the only time the portfolioseller is authorized to initiate settlement is when the collateral isall used; that is, the Current Portfolio Value (CPV) is zero.

This authorization is included to allow the management entity theability to recoup its collateral in the event of a lethargic,unmotivated user who does not request settlement once their portfoliofails to produce returns (essentially, a portfolio dust account). Inthis case, the management entity is left unable to settle the contractand their collateral is subsequently tied up until the user finallyinitiates settlement of the contract or the life of the contractexpires. However, a sellerSettle function can create the aforementionedattack, which is called The Big Grab Attack. It could be executed asfollows: (1) Both the buyer and seller can call the portfolio. Value( )function and this will trigger a request with the oracle for pricingdata. At this point, the nefarious party would push data to the oraclewith all coin prices equal to zero; (2) The contract would then read thevalue of the portfolio as “zero” based on the nefarious party'serroneous data, and subsequently this would authorize the managemententity to call sellerSettle, a function that forces the contract intosettlement; and (3) The contract would attempt to settle the contract byreading data from the oracle; erroneous data pushed by the nefariousparty that values the portfolio at zero, thereby settling the contractin the portfolio seller's favor and subsequently pushing all collateralto the portfolio seller.

In this way, the nefarious party could quickly force all outstandingcontracts into fraudulent settlement based on fraudulent oracle data,thus the name, The Big Grab Attack. Since management entity will bevaluing every contract at least once per day (by calling theportfolio.Value( ) function) then this attack could be executed somewhatquickly.

There are various solutions to this attack. The first is to remove thesellerSettle function while the management entity is the only oracleprovider. Another solution is to secure the oracle so that itsfunctioning is not solely dependent on the management entity. In somecases, the system can do both in order to increase the applicationsecurity on both fronts. However, simply removing sellerSettle woulddefend against this attack, since the nefarious party would have to waitfor the user to request settlement and this by its very nature does nothappen all at once. Thus, the nefarious party would be back in the samesituation where it would have to settle each customer one-by-one witherroneous data; again, a tactic which would be detected very quickly,thus reducing the expected value of such an attack (especially since theuser will be able to “pause” the contract if they suspect fowl play). Iffor some reason the nefarious party tried to do this to every customer,then customers would pause their contract for up to x days and therewould be a long line of angry users outside of the management entity'soffice requesting “fair settlement” to get their money back.

Regarding the oracle, there is an entire section dedicated to how toimplement a secure oracle that will significantly reduce the risk of theoracle outputting false data or getting hacked itself. If thesellerSettle function removed, how than does the system avoid thelanguishing portfolios problem? Efficient collateral management isimportant to the management entity's approach.

In one example, each user was required to send ‘excess collateral’ tothe contract. In the example, it was 25 ETH when the initial portfoliovalue was 100 ETH, and therefore, the collateral ratio was 1.25. If aportfolio's value goes to zero, then the contract will still be holding25 ETH of excess collateral. Instead of allowing the seller to forcesettlement of the portfolio at that point in time, the system will allowthe seller to take a time-based subscription fee on a daily or weeklybasis whenever the contract is valued. For example, the managemententity would charge 1% per month of the total value of the contract forhowever long the contract is open. This is represented in thesellerWithdraw function. When this “excess collateral” goes to zero,then the contract would settle automatically. This is represented as aconditional inside the sellerWithdraw function. By “automatically”, thisdisclosure means that when contracts are evaluated via theportfolio.Value( ) function, the system would add a conditional whichchecks the buyer's excess collateral, and if that number equals zero,then the portfolio will settle based on the prevailing rates from theoracle.

By taking a fee on a weekly or daily basis, and with a collateral ratioof 1.25, the user would be motivated to only use the wallet for itstrading, portfolio management, and follow-leader functions, rather thanas a MyEtherWallet type solution. Additionally, if a user decided to leta contract “languish”, it would not matter to management entity sincemanagement entity is earning fees from that contract at the same rate asany other contract which may be more “active”. The other benefit of thisfee structure is that it scales in proportion to the Total NotionalValue of all Outstanding Contracts (TNVOC); important because managemententity infrastructure costs also scale with the total notional value(i.e. more contracts=more collateral=more hedging=etc.). Again, thecontract would simply settle automatically when all the buyer's excesscollateral was spent; there is no need to give the seller any additionalpowers or authorizations.

Thus, the system will not authorize the management entity to forcesettlement of the contract as it opens up The Big Grab Attack whichincreases custodial risks for the users. A time-based fee hard-codedinto the contract can make the contract automatically settle, motivatesthe user to use the service for its main features, and aligns themanagement entities incentives and costs with the user's likelybehavior. Designing the oracle to produce correct results is furtherdiscussed below.

Next, this disclosure discusses an Attack Surface Mapping and ScenarioAnalysis. In this section, the disclosure looks at possible attackcombinations for all parties that have influence over the contract,which include the portfolio buyer, the portfolio seller, and the oracle.For each party to the contract there are two states from which they act:they are either hacked or not hacked. By being hacked, it is assumedthat they will be acting nefariously and so the system does not have toconsider the situation where they are not hacked but have for somereason decided to act nefariously. For example, a specific user may notbe hacked but may decide to try and cheat the management entity. Eitherway, if the user was hacked or not, they are acting in clearcontradiction to how the contract is designed to operate. Likewise, inThe Big Grab Attack, the management entity could claim to have beenhacked but really just stole them money themselves, either way, thecontract was somehow tricked into not producing the expected results.For example, expected results whose calculation is rather mundane withzero-room for interpretation or subjectivity. For this reason, thefollowing discussion is going to fold the “non-hacked, but nefarious”party into the term “hacked”.

Again, the different states can include: (1) The management entity ishacked: somehow the attacker gets a hold of the private keys associatedwith the management entity's position as the portfolio seller in thecontract; (2) The management entity is not hacked: everything is fine;(3) The user is the hacker: since the attacker can take out swapsanonymously with management entity, then they don't need to hack aspecific user to assume this position in the contract. If they hacked auser, they could simply request settlement and take the funds. Theproduct can let the user manage their own private keys, and so that isthe user's own liability. Thus, this disclosure only needs to considerif the user is actually the attacker; (4) The user is not the hacker:everything is fine; (5) The oracle is hacked: If the oracle iscompromised then the data will be false (not true data); and (6) Theoracle is not hacked: this means the oracle is not compromised,everything is fine, and the data is true.

The above scenarios are discussed now in more detail. Assume the “BigGrab Attack” in which the management entity is hacked, the oracle ishacked and the user is not the hacker. The approach to this scenario wasdiscussed above.

In another scenario, assume the “Hacker Big Grab Attack” in which thecontract state is that the management entity is not hacked, the oracleis hacked, and the user is the hacker. This is a new type of big grabattack. The attack would be executed as follows: (1) Attacker takes outa large number of swaps with the management entity as the buyer; (2)Attacker hacks the oracle; (3) Attacker initiates settlement of theswaps as buyer; and (4) Attacker pushes false data to the oracle.

In this case, the swaps will settle based on false data (inflated coinvalues), and the attacker will gain all of the collateral, andmanagement entity's collateral will be stolen. To defend against thisattack, the system needs to make sure the oracle is secure and hasfailsafes. To do this, a security stack is proposed for the oracle inline with our previous discussions, but with much greater detail andadded solutions. The following is a summary of the solutions which willbe discussed in the oracle design section: (1) A multi-sig and validatororacle: Hacker would need to acquire more than just one key, if not allkeys (M of N keys); (2) An oracle that receives data from multipleexchanges: Hacker would need more than just one key, if not all keys(i.e. hack all exchange oracle keys simultaneously); (3) An oracle thatreceives data from Oraclize: Hacker would need to find a weakness in theOraclize smart contract as well as the TLS Notary technology. (Oraclizeis a Solidity smart contract ensemble designed to make it easy forpeople to set up their own oracles using the public APIs of anywebsite); (4) An oracle that receives “crowdsourced” data-validationfrom a group of users: This is something which the disclosure willelaborate on in the oracle design section. It is possibly the mostdecentralized oracle seen in the industry to date. This solution alsolends itself to token issuance; and/or (5) Many of these layers andsolutions can be combined. For example, one concept proposed iscombining one through three in the product during its early stages ofdevelopment. The goal is actually to push as much risk as possible tothe oracle and design the product to inherently defend against any useror management entity centric attacks. This is an object behind manysmart contracts decentralized applications.

The above introduction to possible oracle solutions relates to oraclesecurity in this attack, but the disclosure also introduces theaforementioned “failsafes” which will also be discussed in greaterdetail later.

One failsafe allows both the buyer and the seller to be authorized to“pause” a contract for some amount of time. The amount of time could be24 hours, 7 days, or one month, or any other amount of time short orlong. It could even be all three, that is, each party can choose forwhat period they want the contract to “pause”. When a party pauses acontract, it deactivates contract functions like buyerWithdraw, or theoracle, etc. This prevents those functions from producing undesirableresults during this period. The “pause” feature can be implemented byusing a multi-signature approach, a joint approach were the buyer andthe seller must both authorize the pause, or an individual approach.Other variations could be built into the process, such as the buyerand/or seller each being given one “free” opportunity the pause thecontract for 24 hours. One party could pay an additional amount of moneyfor additional “pause” rights or time. All such variations are includedwithin this disclosure.

Another failsafe is that each contract will also likely have a“settlement period” wherein even if the settlement calculation goesthrough without issue (that is, the data is true and neither party ishacked) then there could be a certain time before each party is allowedto withdraw funds. On a first glance, this should likely depend on thevalue of the contract, e.g. 24 hour period for contracts whosesettlement value is less than 5 k USD, 48 hours for contracts of 5-20 kUSD, and 7 days for contracts of 20 k USD or higher. Other time framescan also be built in the contract as noted above, such as providinginteractions that urge the buyer or the seller to complete the contractbased on some parameter such as an increasing risk to being hacked basedon one or more of how long the contract has existed, outside externalfactors such as political changes, time of year, personal data about theparties to the contract obtained through social media, predicted issuesthat have a higher probability of occurring in the near or distantfuture, and so forth.

Another failsafe is that both the oracle and each contract itself canhave a “manual override” function. The override acts as “trainingwheels” until the application is “battle tested”. A manual overridefunction essentially allows a small set of trusted individuals (likecurators in DAO) to completely override the contract in a number ofways. One power will be to manually send the contract settlement valuesinstead of the oracle (in case the oracle is hacked). This manualoverride also can have other authorizations.

Yet another failsafe relates to a deployment plan with this applicationwhich is to slowly ramp up both the maximum allowable value for eachcontract as well as the total outstanding value of all contracts. Thesystem starts with small portfolios with a limited number of totalportfolios/contracts that are outstanding/open. As the applicationcontinues to operate securely, the system will increase the allowablevalue of each contract as well as the total outstanding value of allcontracts. This is in contrast to how the DAO operated in that itsolicited massive funds essentially during its alpha phase.

Reverting back to the subject of this specific attack (Hacker Big Grab),an important point to make is that although management entity would loseits collateral, management entity users would not be directly affectedunless they were trying to settle their contract at the exact same timethat the attacker was executing the attack. If this was the case, thenthose users would also be served false data, but likely also getinflated coin prices as this would be how the attacker would get thecollateral pushed to them, and thus the customers would actually be“happy” since their portfolio got settled in their favor, and themanagement entity would lose its collateral.

Another scenario is the “Poor Extortionist Attack” in which the contractstate is that the management entity is not hacked, the oracle is hackedand the user is not the hacker. In this attack, the attacker wouldn'timmediately gain anything since they are not the management entity orthe user. If the attacker has control over the oracle, then why wouldn'tthey just take out a bunch of swaps with the management entity beforehacking the oracle? (This approach would be similar to the Hacker BigGrab Attack). In reality, the hacker probably would, but what if theattacker is poor and doesn't have the capital to post to the swapsbefore taking over the oracle? How else could they monetize their accessto the oracle? These questions shall be addressed next.

In the above scenario, the system would not allow any contracts tosettle by pushing false data to the oracle, like all zero values. Allzero values would make all portfolios worthless (and hence the userwould never ask to settle them). Thus, the attacker could extort themanagement entity users to get their own collateral back by making themsend ethers; or, simply wreak havoc on the entire system for whateverreason. This is an attack with a different execution profile, but withdeleterious results nonetheless.

The inverse of the above attack could be that the attacker decides toinflate all portfolios to high values (makes all coins worth 1M USD)wherein everyone would initiate settlement (free money) and themanagement entity would falsely lose all of its collateral to its users.In this case, the attacker would gain nothing, however all the userswould make gains; the attacker would likely see herself as being somekind of Robin Hood. The defense of this attack again rests with thesecurity of the oracle for which this disclosure touched on in theprevious attack and which is addressed under the oracle design optionsportion.

Another attack scenario is the “Hot Contract Attack”. In this scenario,the contract state is that the management entity is hacked, the oracleis fine, and the user is the hacker. This attack is very similar to whatall exchanges face with having “hot wallets”. Here is how it would beexecuted: (1) Attacker would take out a non-trivial number of swaps withmanagement entity; (2) Attacker would gain control of the portfolioseller role in those swaps by hacking management entity servers; (3)Attacker would initiate settlement of those swaps from the buyer role;and (4) Attacker would get all the collateral since they have assumedboth sides of the swap regardless of oracle settlement data.

In this attack, all non-hacker users would not be affected, but themanagement entity would lose all its collateral. The defense to thisattack depends on operational and business centric rules designed toprotect management entity contract keys. The management entity hasidentified some features which can be programmed into the smart contractthat will help protect the management entity in this attack. Thediscussion of the next attack will demonstrate how these features willhelp the management entity.

The scenario is the “Poor Vampire Attack”. The contract state is thatthe management entity is hacked, the oracle is fine, and the user is notthe hacker. In the past attack, the user is the hacker, and so theywould get all the collateral once they initiate settlement from thebuyer role. In this version, the attacker has gained control over themanagement entity contract keys, but has not taken out a bunch of swapswith the management entity. The reason for this could be the same as inthe Poor Extortionist Attack in that the attacker doesn't have muchcapital to start with, and so she looks to monetize this access inanother way.

In this attack, once the hacker steals the management entity contractkeys, they would just sit and wait for each user to request settlementover time. The management entity would be powerless in this situationand the hacker would slowly drain the collateral out of each contract,like a Vampire, as each user went to settle their contract. However,management entity users would not be affected in this attack since theywould get settled fairly as the oracle is fine.

To reduce the risk and value of this attack, this disclosure proposesthat contracts include a new function designed to invalidate the HotKeys registered in the contract as the portfolio seller role and revertit to a new address which it is called the Back Up Key(s). If the systemsuspects foul play, or if all server-side keys have been compromised,then with one simple call to this function, the system can quicklyinvalidate all active contract keys and revert the portfolio selleraddress to the Back Up Key. There could even be two layers here in thatthere could two or three Back Up Keys. The Back Up Key(s) could begenerated and managed like a cold storage/contract key in that it isnever really exposed to an attacker since it is generated offline, andonly needs to sign a message in the event the system suspects a HotContract key has been compromised, which will hopefully be never.

This disclosure recommends a hack prevention process for any key holderauthorized to push data to the oracle. In this way, no oracleparticipant should ever be able to reasonably claim that their oraclekey was hacked for any meaningful length of time; all they will have todo is use the Back Up Key to invalidate the Hot Key (which in the caseof the oracle will be trivial to detect since there will be severalparties validating the data at each settlement).

In this configuration, the first time management entity notices that anysettlement funds have been diverted out of their control, they cansimply swap any single key—or all keys—long before other user's requestsettlement. This should deter hackers since it is the equivalent of notbeing to do a “big grab” on a centralized exchanges “hot wallet” sincethe hacker would have to wait for each and every user to make awithdrawal request from the exchange to get their money. Userwithdrawals by their very nature do not happen all at once and so theattacker could wait a very long time to drain all the hot wallet funds.Once that first withdrawal/settlement appears compromised, thenmanagement entity can quickly invalidate all the “hot wallet keys” andreplace them with fresh keys. Adding such a key replacement function issecure from a Solidity programming perspective.

This defense significantly reduces the risk of loss during the HotWallet Attack and the Poor Vampire Attack wherein management entitycontract keys are hacked. Again, remember that in both of the attacksnon-hacked PRISM users are not affected.

Another scenario is the “Business As Usual #1”. In this case, thecontract state is that the management entity is not hacked, oracle isfine, and the user is the hacker. There is no application level attackhere. The product is designed to protect management entity against anefarious/hacked user and likewise the product is designed to protectthe user against a nefarious/hacked management entity (with theaforementioned caveats).

Another scenario is the “Business As Usual #2”. In this case, thecontract state is that the management entity is not hacked, oracle isfine, and the user is not the hacker. There is no issue in this case,everything is working fine, and the management entity operates businessas usual.

Another scenario is the “Hell Fire and Brimstone” Attack. In this case,the contract state is that the management entity is hacked, oracle ishacked, and the user is the hacker. In this case, all security featureshave simultaneously failed, the attacker decidedly can do anything uponany party she so pleases. The last three scenarios above are providedfor completeness in the attack scenarios as there are three parties tothe contract, the portfolio buyer, the portfolio seller and the oracle,each if which can be either hacked or not hacked.

After making the design considerations mentioned above, the only attackwhich would hurt users of the disclosed marketplace (PRISM) are thefirst, third and eighth attacks above. With attack #1, the system cansimply remove the sellerSettle function as discussed. At which point,this attack morphs into the third attack, in which just the oracle ishacked and the attacker extorts users to get “fair settlement” (PoorExtortionist Attack). If the last attack occurs, then it will bedifficult. Thus, this is the attack which needs to be defended against.Securing the oracle is paramount to avoiding this attack and so adiscussion of the oracle design and implementation is next.

In this section the disclosure will introduce and discuss the differentoracle design options and see their effects on the oracle's security.The first option with respect to the oracle design is a multi-validatororacle. A multi-signature technology can be implemented for the oracle.If so, for data to be accepted by the oracle as “truth”, it would needto be signed off by M of N parties to the transaction.

Having the oracle be multi-signature applies this level of security andcomfort to the system. There is no altcoin exchange that can claim theyhave multi-sig for all their wallets. This is because it takes time andeffort to build a multi-sig implementation for each and every coin.Thus, the present approach shifts that technical problem directly tosecuring the oracle data rather than the private keys of each coin. Thisalone is interesting from a sales and marketing perspective asmulti-signature is a cryptographic concept and from the outset thesystem can claim to be “more secure” than any centralized exchange(based on the oracle security).

The implementation disclosed herein can implement a re-imagination ofmulti-signature concepts. In the present disclosure, the system can askan entity, such as Bitgo (or any other entity), to not only be a signerbut also validate the oracle data at the same time. This means thatBitgo would have to run an instance of the CoinCap.io API, pulling thesource data from the public APIs of each contributing exchange, runningthe CoinCap.io calculation methodology, and then pushing that data tothe oracle.

In this configuration, Bitgo (or any entity performing this function) isboth a key holder and a validator. The entity would not be blindlysigning oracle data and would have to provide the right result andcorresponding calculation proofs.

As noted above, the entity does not have to be Bitgo, and could be anarray of trusted validators and signors all pulling data from the publicAPIs, producing the calculation results, and when everyone is inagreement, only then signing for the authenticity of this data fororacle use.

The multi-validator process could also be enforced by a single smartcontract itself rather than having the key-derivation function be amulti-signature process. In a pure smart contract implementation, oracledata would not be validated until M of N key-holders signed off on itsauthenticity. The difference in these two approaches could be up fordiscussion based since in multi-signature the source of risk is aCrypto-Primitives Risk versus in the pure smart contract implementationthe source of risk is Solidity Language Risk.

Some of these concepts apply in a pre-Bitfinex hack world, and sinceBitfinex was using Bitgo, there are new product implementations withsuggesting they could be a signor/validator. Until the system knows thesource of the failure for the Bitfinex hack, Bitgo as a specificallysuggested entity may not be an option. Pre-Bitfinex hack, most peoplelikely agreed they would have been a potential good choice for thisrole.

A second option for developing the oracle is the multi-exchange oraclein which the exchanges push data. In this case, the oracle would contactthe exchanges and ask them to push their trading data directly to theoracle. The oracle would only be authorized to receive data from certainEthereum addresses, each of which would be controlled by a differentexchange. The system can also authorize the oracle to receive data fromother addresses from a group of trusted addresses. Each exchange wouldjust push the data from their API directly to the oracle. An attackerwould need to simultaneously compromise each of the exchanges oraclekeys, and then simultaneously push false data to the oracle to executethe attacks previously discussed. Although this does increase thesecurity of the oracle significantly, there are two importantconsiderations which arise from this configuration.

The first is a business development and product-centric consideration.Implementing this type of oracle would require the cooperation of eachexchange. They would have to take responsibility for managing theiroracle key and then pushing the data to the oracle upon request. Manyexchanges may do this to help build the ETH ecosystem, while someexchanges may see PRISM as a competitor for their small/mid-dollarretail clients. Successful exchanges have built liquidity throughattracting all different types of clients including retail clients.Further, a sales and marketing pitch is definitely geared toward showingthat the product has significantly less custodial risk than anyexchange.

The second aspect is a modification on the Hacker Big Grab Attack whichcould be executed by a nefarious exchange instead of an independentattacker of the oracle. Assume that after contacting all the exchangesthat only one exchange agrees to push data to the oracle, e.g. Poloneix.Therefore, all of the oracle data is coming from them. Here is how anattack could execute: (1) Take out a bunch of swaps with managemententity as a series of anonymous users; (2) Request settlement of thoseportfolios from the buyer role; (3) Push fake data to the oracle whicherroneously inflates the value of those users' portfolios; (4) All thecollateral would wrongly get pushed to the buyers; (5) The managemententity then contacts the exchange asking “What's going on with thedata?”; and (6) Exchange claims it was hacked, but quietly makes offwith a fortune.

This attack is called the Nefarious Exchange Big Grab Attack. A solutionto this attack is to have a diversity of exchanges pushing data to theoracle. However, this could create a bottleneck on the flexibility ofthe service since there are some coins which Poloneix does not trade.Conversely, there are some coins that only one exchange trades (e.g.Gatecoin for Augur and DGX IOUs). This attack could be executed againsta single coin portfolio if that coin is only traded on one exchange.Another good solution to this problem reverts back to the processmentioned with Bitgo, in that Bitgo would be pulling the data from theexchanges public APIs. The main benefit here is that the exchangecouldn't claim that its oracle keys were hacked. The only way they couldmanipulate the data at that point would be to orchestrate some type offlash-crash on their order book. This is far more difficult and hasbroader ramifications for the exchange since their own users will beseverely affected by such a flash crash (whereas if they claimed a hackon the oracle, none of their customers would be affected). Further, ifmanagement entity or another party like Bitgo is pulling the data fromthose exchanges, then the system can do sanity checks on the data beforesigning its authenticity to the oracle. For example, if the systemobserves a “flash crash” happening, it simply “pause” transactions bynot signing the oracle data until the “flash crash” is over. The systemwould want to have such sanity checks on trading data for market riskcentric reasons. In the traditional finance world, such “trading pauses”during a flash crash or ultra high volatility period are called “circuitbreakers”. Note that a circuit breaker approach with management entityauthorized to pause settlement would also defend against a Big GrabAttack where the oracle was compromised by an outside attacker (sincethey would try and inflate prices).

Although the approaches herein can implement a process where exchangespush data to the oracle from their own oracle keys, some configurationscan allow an entity to pull the data from public APIs for more securityto the management entity. Additionally, the robustness of the overalloracle (number of coins that can be offered, number of data providers,etc.) will not be dependent on getting each and every exchanges“approval” to use their data for the oracle.

The disclosure now turns to a discussion on Oraclize, which would allowa management entity to pull data from exchanges public APIs withouttheir permission in a “provably honest” way. Another option is to usethe Oraclize Technology and Service. Oraclize is a Solidity smartcontract ensemble designed to help people set up their own oracles usingthe public APIs of any website. It does this through a suite of smartcontracts, a pseudo-centralized service which they provide, and atechnology called TLS Notary which is designed to make their centralizedprocesses “provably honest”. A TLS Notary allows a client to provideevidence to a third party auditory that certain web traffic occurredbetween himself and a server. The evidence is irrefutable as long as theauditor trusts the server's public key. Essentially, Oraclize queries atarget API and then pushes the data to the designated oracle for theapplication.

The following is an example for using Oraclize in the presentapplication. A CoinCap.io instance is set up with Oraclize in whichOraclize, upon every request, pulls data from all the public APIs of allthe exchanges and then computes the resulting values (using theCoinCap.io method). Next, Oraclize pushes the resulting data to theportfolio contracts oracle (that will be used for settlement) and at thesame time includes two things: (1) A TLS Notary proof and (2) Thelocation of the source data and results in the interplanetary filesystem (IPFS). All of this is done through a smart contract except forwhen the data must be queried from the exchanges public API, since smartcontracts cannot reach out to APIs. Thus, the Oraclize centralizedserver makes the query, which is where TLS Notary operates.

TLS Notary can work by generating a cryptographic proof during the TLSHandshake process which allows one to prove to any third party that thedata delivered from the server's HMAC key has not been manipulated byanyone. Therefore, the user is able to prove that the data sent fromthat server has integrity. This is useful because the major risk withusing Oraclize is that it could manipulate the data between when itqueries it from the public API of an exchange and pushes it to theoracle. This would open the process up to a Big Grab Attack sinceOraclize could all of sudden push false data to the oracle and thensettle a bunch of swaps it took out against the management entity.However, with the TLS Notary proof, the management entity canmathematically verify that they have not manipulated the data when itwas sent from the exchange API.

All the management entity has to do once it receives the data is run theverification on the TLS proof and it would know that Oraclize did notchange anything. Of course, the system can also check their result withthe CoinCap.io results and make sure they match. Oraclize stores thesource data, the result, and the TLS Proof in the interplanetary filesystem so that anyone can pull up the file and run the validationindependently without having to request the files from Oraclize.

Another option relates to a Browser Wallet Validation Tool in which theusers derive data. Another interesting way to validate the CoinCapi.iodata is to have the user re-derive it for every settlement. This couldbe done by the user running an instance of the CoinCap.io calculationmethodology but pulling the source data themselves. This could beimplemented as a browser tool in MyEtherWallet or as a desktop toolconnected to Mist/MetaMask. It would work as follows: (1) A user wouldinitiate settlement from the buyer role; (2) The tool would then pullthe public API data and calculate the results; and (3) The tools sendsthat result as a signed message to the oracle. A benefit of thisapproach is that this solution is attached to the private key of theuser's public address in the contract. If every user was pulling andvalidating trading data and then sending the results in a signedmessage, that would be close to a fully decentralized oracle.

Another aspect of this option is that it allows non-technical users toexecute it without their knowledge. For example, if the system wererunning it from MyEtherWallet, then the process would just occurin-browser through JavaScript calls to the public APIs of each exchange.Of course, the big question is what if the user lies about data (changesthe APIs results) for whatever reason. What can be learned in thecrypto-world to disincentivize anonymous users from lying abouttransaction data? The disincentivization can be in requiring a proof ofwork, proof of stake, or another consensus algorithm.

The following is a further possible oracle implementation. Consideringthe options and trade-offs, the following is an example embodiment forthe oracle. In one aspect, 50-100 user contracts with maximum contractvalue of 1 ETH per contract could be implemented. In this initial case,the system would just use CoinCap.io API that will push data directly tooracle. In a later version, 100-200 user contracts are initiated butwith a maximum contract value of 100 ETH and with a Total OutstandingNotional Value of 100 k-300 k USD. In this case, the system would addOraclize CoinCap.io data validation process and provide two contributorsto oracle the management entity (such as a management entity) andOraclize. Thus, a tiered approach to the data validation process couldbe implemented based on one or more factors in the portfolio ofcontracts.

Another version could serve a maximum of 200-400 customers with amaximum contract value of 500 ETH and with a Total Outstanding Notionalof $1M-2M USD. The system could add Bitgo/EtherLi multi-sig to thevalidation process, two signers/validators (2 of 2 multi-sig) and onecontributor (Oraclize) to oracle: management entity, Oraclize, andBitgo/EtherLi. The system would add new sellers to the equation to sharerisk with management entity for collateralizing portfolios, and letsellers be signatory (bump multi-sig) and sellers would have a maximumof 250 k they can use to collateralize (target of 2 sellers on-boarded).

Integrating Oraclize will work since their service is specificallydesigned to make setup of an oracle easy, and this is one of the reasonswhy it is recommended to integrate them first. Having Bitgo be a partyin the transaction is good since: (1) The multi-sig tech is established;(2) the multi-sig tech is pretty simple and EtherLi is functional today,so integration time and effort would be low; and (3) just the salespitch of “crypto-asset portfolios secured by multi-sig/validation model”can make the management entity more secure than any exchange, never mindthat Oraclize is integrated too. From Bitgo's perspective, this could bea lucrative new business model: validating data, computations, and beingan impartial signatory to all types of different oracles.

A user validation tool can also be on the list to combat users forgingdata and trying to trick the system. These decentralized “datavalidation” processes combined with “simple contracts” are the likelynear-term future of Ethereum until the protocol has years of debuggingand testing similar to Bitcoin's protocol progression. A startup calledTruebit by Dr. Christian Reitwiessner is an off-chain data validationtool/process, which publishes proofs to “simple contracts” so that morecomplex computational operations can be securely executed in Ethereum'sframework (rather than coding all the logic to be executed on-chain).Such technologies could be applied here and are incorporated herein byreference.

The following is one possible way in which a settlement can occur inthis configuration: (1) A user requests settlement of their contract;(2) The contract fires a message to Oraclize requesting a settlementresult; (3) Oraclize pulls the data, computes the result, and sends itwith proofs to the oracle; (4) The oracle waits for management entityand Bitgo to validate the results and the proof; (5) The managemententity and Bitgo both sign the result and the proof; (6) The oracletakes the result and sends it to the contract; and (7) Contract makesthe settlement based on the validation oracle data. There are otherimplementations and ways to address this as well and the above providesan example settlement approach.

There are other configurations that can be included and applied as partof this disclosure and application. These options include: (1)Smartcontract.com, (2) Feedbase, (3) PriceGeth, (4) Microtick, etc.Smartcontract.com acts like Oraclize by executing calls to public APIsand then pushing the data to an application oracle. In the presentconfiguration, they could be another “contributor” and also a back-up inthe case that Oraclize fails. They are also working with Brave New Coin,which is a data aggregator of crypto-asset exchange prices and that isthe entity that will be pushing data to the oracle. Feedbase is a simpletool that allows people to push data to the blockchain from geth in astandardized way. This could be employed in the user validation process.PriceGeth is a smart contract and python file/server that is fetchingpoloneix data from the public API and then writing it to the ETHblockchain. This technology is leveraged by the present system based onthe above discussion. Microtick is an implementation of Vitalik'sSchelling Coin paper using the ‘betting’ method as opposed to theconsensus or sampling method. It is a browser implementation. Thedetails of each of these concepts that can be gained through access totheir website is incorporated herein by reference. A number of oracleoptions can be used for increasing the security of any oracle.

Next, the disclosure addresses the attack surface for the oracleconfiguration and scenarios. In the recommended configuration, there aretwo signers/validators and one contributor. This disclosure does notconsider Oraclize to be a “signer” because they are only contributingthe source data and calculation results to the oracle but they will nothave any signing power for authorizing the data to be used in thesettlement of contracts. Rather, it is the job of management entity andBitgo to validate Oraclize data and then sign for its authenticity forthe transactions to go through. While Bitgo is the example, thescenarios could apply to any entity performing a similar function. Thefollowing provides a “name” of a particular scenario, a “state” of thatscenario and a “result”.

Name 1: Business as Usual.

State 1: Oraclize is not hacked, management entity is not hacked, Bitgois not hacked.

Result 1: All data matches, management entity and Bitgo signtransaction, data used for settlement.

Name 2: Paused by management entity.

State 2: Oraclize is not hacked, management entity is hacked, Bitgo isnot hacked.

Result 2: Management entity data does not match. Transaction is paused.Management entity invalidates its primary key with the oracle using theback-up key. Management entity signs data with back-up key andtransaction goes through.

Name 3: Paused by Bitgo.

State 3: Oraclize is not hacked, management entity is not hacked, Bitgois hacked.

Result 3: Bitgo data does not match. Transaction is paused. Bitgoinvalidates its primary key with the oracle using the back-up key. Bitgosigns data with back-up key and transaction goes through.

Name 4: Paused by Signers and oracle Switched #1.

State 4: Oraclize is not hacked, management entity is hacked, Bitgo ishacked.

Result 4: The management entity and Bitgo data does not match Oraclize.Transaction is paused. Bitgo and management entity invalidate theirprimary keys with the oracle using the back-up key. Both signs thetransaction using back up keys and data is used for settlement.

Name 5: Paused by Signers and oracle Switched #2.

State 5: Oraclize is hacked, management entity is not hacked, Bitgo isnot hacked.

Result 5: The management entity and Bitgo data does not match Oraclize.Transaction is paused. If Oraclize protocol is cryptographically broken,then the system has to remove them as a data source from the oracle.

How would removing them from the data source be accomplished? Thisdisclosure introduces a function called “oracle override”. This functioncan be called by two of the three parties. The keys for the oracleoverride function are separate from the primary and backup signing keysfor data validation, and so the override keys will always be held incold storage until this event occurs (hopefully never). To repair theoracle in this situation, management entity and Bitgo call the oracleoverride function and appoint management entity as the new oracle datasource. Both management entity and Bitgo sign the new data and thetransaction goes through.

Name 6: Paused by Bitgo and oracle Switched.

State 6: Oraclize is hacked, management entity is hacked, Bitgo is nothacked.

Result 6: The management entity and Oraclize data does not match Bitgodata. The management entity invalidates primary oracle keys with back upkeys. If Oraclize protocol is broken, the management entity and Bitgoretrieve Override Keys from cold storage and authorize the oracle toswitch to CoinCap.io data. The management entity and Bitgo sign correctdata and transaction goes through.

Name 7: Paused by management entity and oracle Switched.

State 7: Oraclize is hacked, management entity is not hacked, Bitgo ishacked.

Result 7: Bitgo and Oraclize data does not match management entity.Bitgo invalidates primary oracle keys with back up keys. If Oraclizeprotocol is broken, management entity and Bitgo retrieve Override Keysfrom cold storage and authorize the oracle to switch to CoinCap.io data.The management entity and Bitgo sign correct data and transaction goesthrough.

Name 8: Hell Fire and Brimstone, Again.

State 8: Oraclize is hacked, management entity is hacked, Bitgo ishacked.

Result 8: Attacker has broken the protocol and can do whatever shewants. The novelty here is to make the total expected value of a hackless than the effort and combined expertise required to execute thehack; i.e. the Total Notional Value of Outstanding Contracts is 1M USD,not 214M USD, like the DAO. However, this level oracle security couldhandle up to 25M USD easily. Bitgo is already securing more than thatwith its Bitcoin solutions.

Since there are three parties to the oracle: management entity, Bitgo,and Oraclize, and two possible states per party (hacked or not hacked),then the total attack surface is 2*2*2=8 scenarios. Thus, all thescenarios are covered.

Next, the application addresses manual override, speed bumps, andtraining wheels. In the last discussion of the oracle, the ability to“pause” the contract by either of the two signing parties was introducedshould it appear that something is amiss. The oracle override functionwas also introduced, a function which acts as an escape hatch should theOraclize service get hacked. Lastly, an off-chain multi-validator modelwas introduced in which three different parties made calls to the publicAPIs of the source data and then derived the results by running aninstance of the CoinCap.io calculation methodology.

The following extends these same concepts directly to each and everycontract itself. As mentioned above, this disclosure must also develop aplan to deal with Solidity Language Risk both known and unknown. In thecase of unknown bugs, the best that can be done is: (1) Add the abilityto pause a contract for a certain amount of time. This equates tofreezing the contracts state and select functions for all parties; (2)Add a manual override function which allows a contract to be settledbased on manual inputs from a group of trusted validators; and (3)Open-source the contract validation and monitoring tools whichmanagement entity has developed for their own internal purposes. In thisway, anyone can use them to validate that contracts are behaving asplanned.

Expanding on the third point, one could implement this entireapplication via off-chain logic and several validators. That is, onecould remove almost all the logic currently coded in the Solidity filesand instead use an escrow contract that sends funds to each party basedon the collective agreement of the settlement amounts by the seller, thebuyer, and any number of third-party Arbitrators/Validators.

Instead, the present disclosure proposes to use a Training Wheelsconfiguration where much of the logic stays on-chain but a certain setof validators/signers will be able to manually override/settle, pause,or cancel a contract if it's not behaving as expected. Thesevalidators/signers could be the same as in the oracle (Bitgo), oranother set of publicly identified arbitrators (Roger Ver, for example).

This configuration can be thought of as a type of “Training Wheels”configuration for the application because more code is left on-chain buthave trusted parties who can jump to the rescue the contract if thingsdo not work. As mentioned previously, the goal with one embodiment ofthis disclosure is for it to have significantly “less trust” than thecurrent alternatives in the marketplace, all of which arehighly-centralized blockchain asset exchanges. With all of the riskplaced on the oracle, and with an open and transparent oracle processthat involves three separate parties rather than one (like currentexchanges) big improvements to the fully centralized model thatcurrently dominates the marketplace have been presented.

An example embodiment of the concepts disclosed herein includes acomputer-readable storage device. The computer-readable storage deviceis a man-made physical device such as RAM, ROM, a hard drive, opticaldrive, or any other device that can store instructions which, whenexecuted by a processor, can cause the processor to perform operationsincluding any one or more of the steps or processes disclosed herein.The computer-readable storage device excludes signals per se and thelike.

The present examples are to be considered as illustrative and notrestrictive, and the examples is not to be limited to the details givenherein, but may be modified within the scope of the appended claims. Itis further noted that any feature of any example or any embodiment maybe mixed with any other feature disclosed herein. Any method embodimentwhich includes a series of steps may also include, as one aspect, onlyone or two of the listed steps. The order of the listed steps may alsobe modified and performed in any order unless explicitly required.

Claim language reciting “at least one of” a set indicates that onemember of the set or multiple members of the set satisfy the claim. Forexample, claim language reciting “at least one of A and B” means A, B,or A and B. Use of the terms “at least one of” to describe a list ofitems separated by the term “and” should not be interpreted to mean thatthe list requires one of each item in the list, but rather that the listincludes at least one item in the list, which can be any item or numberof items in the list, such as the full set of items in the list, asubset of items in the list, or a single item in the list.

Statements of the Disclosure Include:

Statement 1: A method comprising: establishing a multi-asset blockchainbased trustless smart contract associated with a multi-asset portfolio;inserting, into the multi-asset blockchain based trustless smartcontract, an authorization for a leader multi-asset blockchain basedtrustless smart contract to send messages from the leader multi-assetblockchain based trustless smart contract to the multi-asset blockchainbased trustless smart contract to yield a follower multi-assetblockchain based trustless smart contract, the messages regarding aleader rebalancing of the multi-asset blockchain based trustless smartcontract; receiving a message from the leader multi-asset blockchainbased trustless smart contract indicating a leader rebalancing of theleader multi-asset blockchain based trustless smart contract; andmodifying the follower multi-asset blockchain based trustless smartcontract based at least in part on the leader rebalancing of the leadermulti-asset blockchain based trustless smart contract.

Statement 2: The method according to Statement 1, wherein the modifyingof the follower multi-asset blockchain based trustless smart contractcomprises rebalancing the follower multi-asset blockchain basedtrustless smart contract to match the leader rebalancing.

Statement 3: The method according to Statement 1 or Statement 2, whereinthe modifying of the follower multi-asset blockchain based trustlesssmart contract comprises a follower rebalancing of the followermulti-asset blockchain based trustless smart contract that follows aportion of the leader rebalancing.

Statement 4: The method according to any one of Statements 1 to 3,wherein the leader multi-asset blockchain based trustless smart contractcan only send rebalancing messages to the follower multi-assetblockchain based trustless smart contract.

Statement 5: The method according to any one of Statements 1 to 4,further comprising: receiving market data at the follower multi-assetblockchain based trustless smart contract prior to modifying thefollower multi-asset blockchain based trustless smart contract; whereinthe modifying of the follower multi-asset blockchain based trustlesssmart contract is based on the market data and the leader rebalancing.

Statement 6: The method according to any one of Statements 1 to 5,wherein the follower multi-asset blockchain based trustless smartcontract is modified for a percentage of the leader rebalancing.

Statement 7: The method according to any one of Statements 1 to 6,wherein the modifying occurs one of immediately or in a predeterminedtime after receiving the leader rebalancing.

Statement 8: A system comprising one or more processors and at least onecomputer-readable storage device having stored therein instructionswhich, when executed by the one or more processors, cause the one ormore processors to perform a method according to any one of Statements 1to 7.

Statement 9: At least one computer-readable storage device having storedtherein instructions which, when executed by the one or more processors,cause the one or more processors to perform a method according to anyone of Statements 1 to 7.

Statement 10: A system comprising means for performing a methodaccording to any one of Statements 1 to 7.

What is claimed is:
 1. A method comprising: establishing a multi-assetblockchain based trustless smart contract associated with a multi-assetportfolio; inserting, into the multi-asset blockchain based trustlesssmart contract, an authorization for a leader multi-asset blockchainbased trustless smart contract to send messages from the leadermulti-asset blockchain based trustless smart contract to the multi-assetblockchain based trustless smart contract to yield a followermulti-asset blockchain based trustless smart contract, the messagesregarding a leader rebalancing of the multi-asset blockchain basedtrustless smart contract; receiving a message from the leadermulti-asset blockchain based trustless smart contract indicating aleader rebalancing of the leader multi-asset blockchain based trustlesssmart contract; and modifying the follower multi-asset blockchain basedtrustless smart contract based at least in part on the leaderrebalancing of the leader multi-asset blockchain based trustless smartcontract.
 2. The method of claim 1, wherein the modifying of thefollower multi-asset blockchain based trustless smart contract comprisesrebalancing the follower multi-asset blockchain based trustless smartcontract to match the leader rebalancing.
 3. The method of claim 1,wherein the modifying of the follower multi-asset blockchain basedtrustless smart contract comprises a follower rebalancing of thefollower multi-asset blockchain based trustless smart contract thatfollows a portion of the leader rebalancing.
 4. The method of claim 1,wherein the leader multi-asset blockchain based trustless smart contractcan only send rebalancing messages to the follower multi-assetblockchain based trustless smart contract.
 5. The method of claim 1,further comprising: receiving market data at the follower multi-assetblockchain based trustless smart contract prior to modifying thefollower multi-asset blockchain based trustless smart contract; whereinthe modifying of the follower multi-asset blockchain based trustlesssmart contract is based on the market data and the leader rebalancing.6. The method of claim 1, wherein the follower multi-asset blockchainbased trustless smart contract is modified for a percentage of theleader rebalancing.
 7. The method of claim 1, wherein the modifyingoccurs one of immediately or in a predetermined time after receiving theleader rebalancing.
 8. A system comprising: one or more processors; anda computer-readable medium, storing instructions which, when executed bythe one or more processors, cause the one or more processors to performoperations comprising: establishing a multi-asset blockchain basedtrustless smart contract for managing a multi-asset portfolio;inserting, into the multi-asset blockchain based trustless smartcontract, an authorization for a leader multi-asset blockchain basedtrustless smart contract to send messages from the leader multi-assetblockchain based trustless smart contract to the multi-asset blockchainbased trustless smart contract to yield a follower multi-assetblockchain based trustless smart contract, the messages regarding aleader rebalancing of the follower multi-asset blockchain basedtrustless smart contract; receiving a message from the leadermulti-asset blockchain based trustless smart contract indicating aleader rebalancing of the leader multi-asset blockchain based trustlesssmart contract; and modifying the follower multi-asset blockchain basedtrustless smart contract based at least in part on the leaderrebalancing of the leader multi-asset blockchain based trustless smartcontract.
 9. The system of claim 8, wherein the modifying of thefollower multi-asset blockchain based trustless smart contract comprisesrebalancing the follower multi-asset blockchain based trustless smartcontract to match the leader rebalancing.
 10. The system of claim 8,wherein the modifying of the follower multi-asset blockchain basedtrustless smart contract comprises rebalancing the follower multi-assetblockchain based trustless smart contract to follow a portion of theleader rebalancing.
 11. The system of claim 8, wherein the authorizationcomprises a requirement that rebalancing messages from the leadermulti-asset blockchain based trustless smart contract to the followermulti-asset blockchain based trustless smart contract be sent directlyfrom the leader multi-asset blockchain based trustless smart contract tothe follower multi-asset blockchain based trustless smart contract. 12.The system of claim 8, wherein the computer-readable medium storesadditional instructions which, when executed by the one or moreprocessors, cause the one or more processors to perform operationsfurther comprising: receiving market data at the multi-asset blockchainbased trustless smart contract prior to modifying the followermulti-asset blockchain based trustless smart contract; wherein themodifying of the follower multi-asset blockchain based trustless smartcontract is based on the market data and the leader rebalancing.
 13. Thesystem of claim 8, wherein the follower multi-asset blockchain basedtrustless smart contract is modified for a percentage of the leaderrebalancing.
 14. The system of claim 8, wherein the modifying occurs oneof immediately or in a predetermined time after receiving the leaderrebalancing
 15. A computer-readable storage device storing instructionswhich, when executed by a processor, cause the processor to performoperations comprising: establishing a multi-asset blockchain basedtrustless smart contract for managing a multi-asset portfolio;inserting, into the multi-asset blockchain based trustless smartcontract, an authorization for a leader multi-asset blockchain basedtrustless smart contract to send messages from the leader multi-assetblockchain based trustless smart contract to the multi-asset blockchainbased trustless smart contract to yield a follower multi-assetblockchain based trustless smart contract, the messages being associatedwith a leader rebalancing of the follower multi-asset blockchain basedtrustless smart contract; receiving a message from the leadermulti-asset blockchain based trustless smart contract indicating aleader rebalancing of the leader multi-asset blockchain based trustlesssmart contract; and modifying the follower multi-asset blockchain basedtrustless smart contract based at least in part on the leaderrebalancing of the leader multi-asset blockchain based trustless smartcontract.
 16. The computer-readable storage device of claim 15, whereinthe modifying of the follower multi-asset blockchain based trustlesssmart contract comprises rebalancing the follower multi-asset blockchainbased trustless smart contract to match the leader rebalancing.
 17. Thecomputer-readable storage device of claim 15, wherein the modifying ofthe follower multi-asset blockchain based trustless smart contractcomprises a follower rebalancing of the follower multi-asset blockchainbased trustless smart contract that follows a portion or a subset of theleader rebalancing.
 18. The computer-readable storage device of claim15, wherein the leader multi-asset blockchain based trustless smartcontract can only send rebalancing messages to the follower multi-assetblockchain based trustless smart contract.
 19. The computer-readablestorage device of claim 15, wherein the computer-readable storage devicestores additional instructions which, when executed by the processor,cause the processor to perform further operations comprising: receivingmarket data at the multi-asset blockchain based trustless smart contractprior to modifying the multi-asset blockchain based trustless smartcontract such that the modifying takes into account both the market dataand the leader rebalancing.
 20. The computer-readable storage device ofclaim 15, wherein the follower multi-asset blockchain based trustlesssmart contract is modified for a percentage of the leader rebalancing.